- PR -

「簡単に作れる」なんて言うから

参照元記事 | 同じ記事を参照しているスレッド一覧
«前のページへ 1|2|3|4|5|6|7|8 次のページへ»
投稿者投稿内容
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2004-07-20 18:55
引用:

objectさんの書き込み (2004-07-20 18:28) より:
しかし、「Java」には
「プロパティ」
「イベント」
が無い訳ですから、「プロパティ」、「イベント」という概念を使うのであれば、それをシッカリ言語
として導入すべきだと思います。

しかし、導入しないのであれば、「Java」のスタンスを明確にして、「プロパティ」、「イベント」に
変わる概念を「Java言語」として確立する方が私は良いと思った次第です。

JavaBeans仕様では不足でしょうか?
標準仕様が確立されており、APIも用意されていますから、「スタンス」は明確だと思いますが。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2004-07-21 12:20
objectです。

>ukさん
私のレス（投稿日時: 2004-07-20 18:28）の中で
>基本的な説明は上記で行っていますが、少し補足すると、
>「Java」に於いても
>「情報」
>「振る舞い」
>の二つが基本であった筈ですよね。
>しかし、「Java」に於いては
>「クラス」は、パブリックなフィールドを使えばどうにか「情報」を記述出来ますが、
>「インターフェース」に於いては、
>「振る舞い」
>しか記述出来ません。
>この一貫性の無さは、「コンポーネント」以前の問題ではないでしょうか？
に関しては、どう思われますか？

「プロパティ」は、「Java」自体がその上で成り立つ「基盤」とも言えるものだと私は思っています。
従って、「Java」が「プロパティ」を言語の中で明確に位置付けないと駄目だと、私は思っています。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-07-21 15:35
引用:

objectさんの書き込み (2004-07-20 18:28) より:

例えば、「RAD」に於ける主対象である
「プロパティ」
「イベント」
ですね。
（中略）
しかし、「Java」に於いては
「クラス」は、パブリックなフィールドを使えばどうにか「情報」を記述出来ますが、
「インターフェース」に於いては、
「振る舞い」
しか記述出来ません。
この一貫性の無さは、「コンポーネント」以前の問題ではないでしょうか？

う〜ん、「透過性」という文字と、そこから想像される意味に結びつきませんが、「Javaにおける一貫性のなさ」は、なんとなくわかりました。情報を定義しながら、情報にアクセスする為に実際には「振る舞い」を利用している（.NETなどは振る舞いをうまく隠蔽できている）、というところですか？


　C++の後発としては、うまく作っているなぁ、と思うけれど、C#を先に触った身としては、面倒くさいなぁ、という感が否めない。。。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2004-07-21 18:20
objectです。

>Jittaさん
>う〜ん、「透過性」という文字と、そこから想像される意味に結びつきませんが、「Javaにおける一貫性
>のなさ」は、なんとなくわかりました。情報を定義しながら、情報にアクセスする為に実際には「振る舞
>い」を利用している（.NETなどは振る舞いをうまく隠蔽できている）、というところですか？
「透過性」に付いては、
「.NET」の「プロパティ・イベント」に対する設定アクション
と
それに対して「IDEツール」が作成した「コード」
をみて違和感があるかどうかを考えれば、ある程度理解出来るのではないでしょうか？

>「Javaにおける一貫性のなさ」は、なんとなくわかりました。情報を定義しながら、情報にアクセスする
>為に実際には「振る舞い」を利用している（.NETなどは振る舞いをうまく隠蔽できている）、というところ
>ですか？
私の「一貫性のなさ」という表現は、本当は「かなり抑えた表現」なんです。
もっと正確にいうと、
「クラス」と「インターフェース」のこの不備は、本当は致命的な欠陥だと私は思っています。

それから、Jittaさんの
「（.NETなどは振る舞いをうまく隠蔽できている）」
という表現の裏に、「少し誤解があるのかな？」という気がします。

>C++の後発としては、うまく作っているなぁ、と思うけれど、C#を先に触った身としては、面倒くさいな
>ぁ、という感が否めない。。。
「うまく作っている」というより、私は設計者が「本質」を理解したと感じていますけどね…。

それから、「面倒くさいなぁ」というのはどの点に関してでしょうか？
skulker
ベテラン
会議室デビュー日: 2004/06/08
投稿数: 67
投稿日時: 2004-07-21 20:05
私はクライアントがクラスの構造なんて知る必要はない(クラスの提供するサービス == 振る舞い だけ知っていればよい)と思うので、インターフェースが構造を表現できない事が欠陥だとは感じません。

Javaの抽象クラスとインターフェース、似たような言語要素がふたつあるのは確かに不恰好だとは感じますが(私はPerlみたいなTMTOWTDIはあまり好きではありません)、やり始めると解決すべき問題がたくさん出てくる実装の多重継承を回避しつつ、しかし多重継承を実現する為に、敢えてメソッドのシグネチャしか持たないインターフェースというものを定義したのは、現実的な解決策だと思います。

総じてJavaはベストではないにせよ、いい具合に枯れた技術に基づく現実的な選択をしていると感じます。理論的一貫性を追求していたら、他のアカデミックな言語同様にマイナーに終わっていたでしょう。
浅学にしてC#については知りませんが、Microsoft社製なのですからWindowsアプリケーション作成、VB出身者に解りやすいのだろうとは思います。
丘波乗
会議室デビュー日: 2004/04/13
投稿数: 6
投稿日時: 2004-07-21 22:32
引用:

objectさんの書き込み (2004-07-21 18:20) より:

>Jittaさん
>う〜ん、「透過性」という文字と、そこから想像される意味に結びつきませんが、「Javaにおける一貫性
>のなさ」は、なんとなくわかりました。情報を定義しながら、情報にアクセスする為に実際には「振る舞
>い」を利用している（.NETなどは振る舞いをうまく隠蔽できている）、というところですか？
「透過性」に付いては、
「.NET」の「プロパティ・イベント」に対する設定アクション
と
それに対して「IDEツール」が作成した「コード」
をみて違和感があるかどうかを考えれば、ある程度理解出来るのではないでしょうか？


私もJittaさん同様、Objectさんのおっしゃる『透過性』の意味がよく理解できません。
『透過性』の定義って『特定のサービスを、提供側を意識せず教授できる』ですよね。
言語と統合環境のサポートにより「イベント」「プロパティ」が簡単に扱えるということでしょうか？
大変恐縮ですがもう少し具体的にご教示頂けますか？
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2004-07-22 12:17
objectです。

>skulkerさん
>私はクライアントがクラスの構造なんて知る必要はない(クラスの提供するサービス == 振る舞い だけ
>知っていればよい)と思うので、インターフェースが構造を表現できない事が欠陥だとは感じません。
「クライアント」という言葉は、「言語」を使う側を指してるんですよね？
私は、「言語」を使う側に、「言語」の選択権がある限り、全責任があると思っています。

>Javaの抽象クラスとインターフェース、似たような言語要素がふたつあるのは確かに不恰好だとは感じ
>ますが(私はPerlみたいなTMTOWTDIはあまり好きではありません)、やり始めると解決すべき問題がたく
>さん出てくる実装の多重継承を回避しつつ、しかし多重継承を実現する為に、敢えてメソッドのシグネ
>チャしか持たないインターフェースというものを定義したのは、現実的な解決策だと思います。
私は、矛盾が起きない限り、「似たような言語要素がふたつある」事自体は問題では無いと思います。
「クラス」概念の基本は、「情報・振る舞い」という「カテゴリ」で「多重継承の概念世界」を「類別」する事だと思います。
でも、それを「補助」する「インターフェース」が「振る舞い」しか表現出来なくて、本当に良いんでしょうか？
「Delphi・.NET系言語」は、「プロパティ」で「クラス・インターフェース」の両方に対して、「情報」を表現する「実例」を示しているんですよ？

>総じてJavaはベストではないにせよ、いい具合に枯れた技術に基づく現実的な選択をしていると感じま
>す。理論的一貫性を追求していたら、他のアカデミックな言語同様にマイナーに終わっていたでしょう。
「理論的一貫性」という言葉で問題を「曖昧」にしている様に感じます。
#私は、全く逆の意味で、「一貫性のなさ」という表現を別の表現にした訳です。

言葉は、基本的な部分で「矛盾」を持てば、「破綻」すると思います。
そういう意味では、「クラス」も「振る舞い」だけという選択肢もあると、私は思いますが…。
#最終的には、「Java」ユーザーに対する影響が少しでも小さくなる事が大切だと思います。


>丘波乗さん
>私もJittaさん同様、Objectさんのおっしゃる『透過性』の意味がよく理解できません。
>『透過性』の定義って『特定のサービスを、提供側を意識せず教授できる』ですよね。
>言語と統合環境のサポートにより「イベント」「プロパティ」が簡単に扱えるということでしょうか？
>大変恐縮ですがもう少し具体的にご教示頂けますか？
確かに、『提供側を意識せず教授できる』という様な意味もありますね。
私が『透過性』に込めた意味は、
「ツール」が行っている内容が「不透明では無い」という意味です。

>言語と統合環境のサポートにより「イベント」「プロパティ」が簡単に扱えるということでしょうか？
「イベント」は、「デリゲート」に対する「プロパティ」だと思います。

つまり、
言語に於ける「プロパティ」概念が、「情報」要素に対する表現を保証し、
結果として
「ツール」が「プロパティ・イベント」を簡単に扱える。
という事ではないでしょうか？


[ メッセージ編集済み 編集者: object 編集日時 2004-07-22 12:46 ]
skulker
ベテラン
会議室デビュー日: 2004/06/08
投稿数: 67
投稿日時: 2004-07-22 15:19
引用:

objectさんの書き込み (2004-07-22 12:17) より:
「クライアント」という言葉は、「言語」を使う側を指してるんですよね？
私は、「言語」を使う側に、「言語」の選択権がある限り、全責任があると思っています。

いいえ、ここでいうクライアントとはクラスのクライアント、すなわちクラスを利用する他のクラスやそれをつくるプログラマを指しています。言葉が足りませんでしたね。

引用:

「クラス」概念の基本は、「情報・振る舞い」という「カテゴリ」で「多重継承の概念世界」を「類別」する事だと思います。
でも、それを「補助」する「インターフェース」が「振る舞い」しか表現出来なくて、本当に良いんでしょうか？
「Delphi・.NET系言語」は、「プロパティ」で「クラス・インターフェース」の両方に対して、「情報」を表現する「実例」を示しているんですよ？

このくだりの意味するところがぴんと来ないのですが(特に「多重継承の概念世界」)、私は世の中をclassifyしているのは実際にはクラスでなくタイプであり、クラスはタイプの実装だと考えています。

ここでのタイプはいわゆる抽象データ型であり、その構造は隠蔽され、サービス(振る舞い)だけが公開されています。
クラスはタイプの実装であり、タイプが提供すべきサービスを実装するにあたって、必要な情報を内部に保持しなければなりません。すなわち、構造(==内部でどのように状態、情報を保持しているかの詳細)を持ちます。

しかし、それをユーザーに教える必要はありません。ユーザーはクラスの構造を知る必要はなく、どうすればオブジェクトの状態を知る事ができるか、変化させられるか、そういったサービスの利用法(振る舞い、事前条件と事後条件)だけを知っていればいいのです。

Javaのインターフェースはタイプに相当させる意図で作られた言語要素だと思います。であれば構造に関する情報を提供しないのは当然です。「こうすれば内部の情報にアクセスできる」という振る舞い(アクセサ)が定義されていれば充分です。その意味ではJavaのものの考え方は一貫していると思います。
プログラマがアクセサを定義する必要があるか、プロパティという言語要素でそれをカバーするかの違いではありませんか? (私は C# を知りませんので推測に過ぎません)

引用:

確かに、『提供側を意識せず教授できる』という様な意味もありますね。
私が『透過性』に込めた意味は、
「ツール」が行っている内容が「不透明では無い」という意味です。

コンピュータに関する文脈で「透過性」という場合、普通は丘波乗さんの言う意味で使われると思います。
透過プロキシーはユーザーに見えないから透過的なんですよね? プロキシーが何をやってるか、そもそもいるのかいないのかなんてユーザーは関知しません。つまりObjectさんのいう「不透明」な状態です。この場合他の用語の方が適当かと思います。代わる言葉を思いつかないんですが・・・。
«前のページへ 1|2|3|4|5|6|7|8 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）