- - PR -
OOPがよくわかりません
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2002-12-12 15:22
どんどん表題とはなれてしまっていますが.
まず、すべてのクラスライブラリにおいて属性を見なれば開発ができないか再度考えてみてください。 見なければいけないクラスライブラリはたしかにあります。 それは設計が洗練されていない事がよくあります。 AWTはそれほど綺麗だとは思えません。 # というかきたない気もする、、 ちなみにぼくは GUIはSWT利用しはじめてます. http://www3.vis.ne.jp/~asaki/java/eclipse/swt.html awt,swing利用するよりもライブラリのソースまで見て属性覗く機会は少なくなるのでは？ JavaDocに関してもいろいろ見方はありますが、拡張Doclet使えばいいだけなので、標準Docletに関してはあれはあれでありだと思っています。 参考になれば。 | ||||
|
投稿日時: 2002-12-12 16:17
unibon です。こんにちわ。
私の考えはつぎのとおりです。 カプセル化をひとまず棚上げして考えたい。 ↓ ではフィールドに直アクセスを許すということか、 と言われれば、コーディングレベルならば、直アクセスはメリットはないので、 なんらかのアクセッサは付けるべきであろう。 ↓ ただ、アクセッサが単にフィールドの読み書きに 一対一に対応する低機能なものならば、あまり意味はない。 ↓ じゃあ、アクセッサを高機能にしたり、付けなかったりすべきではないか、 と言われれば、そうすべきだ。 ↓ しかし、それだとカプセル化したことになってしまう。 ↓ (振り出しに戻る) ご質問の意図があまりよく把握できていないのですが、 「鶏が先か卵が先か」というのはこのようなことを指されているのでしょうか。 [ メッセージ編集済み 編集者: unibon 編集日時 2002-12-12 16:19 ] | ||||
|
投稿日時: 2002-12-12 17:19
tarnwoです。
こんにちは。
クラスを設計する上で，属性が先か，メソッドが先か ということをおっしゃっているのならば，の意味です。 Writing Robust Java Code以外にも Code Conventions for the Java Programming Languageにおいても， 「本質的に動作を持たないデータ構造のためのクラスである場合にのみ public なインスタンス変数が許される」と書かれています。 となると，前提がカプセル化(として設計すべき)に思えます。 ＃もちろん，Sunのソース自体が規約に完全に従っているかといえば Noであることはわかっています。 そういう意味で「直アクセスはメリットがない」と理解しておられるようですが， 属性は皆publicでも良い，と書かれていたのはなぜなのでしょう，ということでした。 ＃個人的には，どうしても将来的な事を念頭においているので， カプセル化の重要性を推してしまいます。 | ||||
|
投稿日時: 2002-12-13 12:43
元々の質問者であるjackさんの書き込みが無いまま、主旨から
外れた宗教戦争の様相を呈してきたので、ここは一つ別のスレ ッドにしませんかね。それぞれの主張に一理があるとは思うの ですが、なにぶん掲示板で見つづけるには辛い長さになっている ようですし。OOPがよくわからないから始まったのに、ますます とっつきにくい感じになったっすよ。話しの前提条件がかなり 食違っている上で話題が進んでるのが問題なんですよね。そこ からすり合わせていかないと、だらだら長いだけの反論合戦が 続いてしまうなー。 | ||||
|
投稿日時: 2002-12-15 01:53
unibon です。こんにちわ。
スレッドを分ける提案は否定しません。 しかし、今後このスレッドに書くべきではない、 という提案ではないと捉えてよいでしょうか。 表立って書くことではないのかもしれませんが、 私は、スレッドを分けても良いが、分けることが必須であるとは考えていないので、 このようなことをあえて書きました (分けなくてよい、ということを書かないと、 分けたほうがよい、という意見だけが残ることになるため、 分けなくてよいということを、あえて表明します)。 これは、分ける提案だけがあって、新規スレッドが作成されていないと、 今までの話題に続けて投稿しようとされるかたがいても投稿しづらくなってしまうと 考えるためです。 では、私(unibon)が新規スレッドを作成すればよい、 というご意見が出るかもしれませんが、 私は上述のようにスレッドを分ける必要性を感じていないし、 分ける理由が私には不明確(分ける判断基準が分からない)なためです。 私以外のかたでも、どんなタイトルのスレッドを作成すればよいか、 戸惑って、結局スレッドを作成できないかたもいらっしゃるのでは、 と推測します。 なお、このような話題(スレッド)について、もし議論を続ける場合は、 このフォーラムではなく「＠ITクラブ Cafe」が適切だと思われるので、 そこで議論することを提案します。 「＠ITクラブ Cafe」に移ったほうがよい理由は、 技術的な議論ではないためです。 スレッドのタイトルは「スレッドを分けるかどうかの基準は?」で、 私が作成させていただきます。 | ||||
|
投稿日時: 2002-12-26 00:36
unibon です。こんにちわ。
その後、いろいろと参考になるものを調べていたのですが、 こちらの @IT のサイトの中の、 Top > Java Solution > 連載：初歩のUML 第2回 クラス図の詳細化とその目的 http://www.atmarkit.co.jp/fjava/rensai/uml02/uml02.html の中の「図2 モデル図における関連名の役割」を見つけました。 これを見ての私の理解としては、クラス図の詳細化の段階においては、 関連名を明確にすることにより、メッセージの意味が限定される。 実装時に、関連はフィールドに落とし込まれ、 メッセージはすなわち操作(メソッド)なので、 結局は、フィールドを詳細化することが、メソッドの詳細化につながる、 と言えると思います。 | ||||
|
投稿日時: 2003-01-16 12:54
unibon です。こんにちわ。
＃思い出した時に、断片的なものを継ぎ足していますが。 その後、書籍、 オブジェクト指向システム開発 本位田真一・山城明宏 著 日経BP社発行 ISBN4-8222-7162-5 http://store.nikkeibp.co.jp/item/main/148222716250.html の中の 「3.18 手法の事例10 : メソッドとメッセージ」 の部分を読みましたが、そこでは、 Shlaer&Mellor(シュレイアー&メラー)手法の分析段階では、 属性はあるがメソッドが存在しないということが書かれています。あまり聞かない手法ですが。 | ||||
|
投稿日時: 2003-01-16 16:05
ＯＯＰたとえ話・・・
ＢＩＧＯＢＪ「ご主人様、なんなりと仰せ付けください」 ＭＡＳＴＥＲＯＢＪ「では紅茶を入れてくれ」 ＢＩＧＯＢＪ「かしこまりました」 ＭＡＳＴＥＲＯＢＪ「なんじゃこれは？」 ＢＩＧＯＢＪ「緑茶でございます」 ＰＧ（うーん、紅茶作成メソッドがおかしいみたいだな） ＰＧ（うん？紅茶作成メソッドはどこもおかしくないな？うーん？どこだ？） おちまい。 って、これではＯＯにした意味が無いですよ。 教訓： 紅茶作成は紅茶クラスにお願いしましょう。 ＃すいません。へんな話しで。 ＃ＯＯの目的って人間が自然な形で理解し作成できることだとか高尚な本にはありますけど ＃実際のプログラミングでは分割統治をやるのにもってこいっていうのが一番の利点ではないかと。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。