OOPがよくわかりません

tarnwoさんの書き込み (2002-12-10 15:09) より:
すべてのフィールドを public にすることは危険です。
外側のクラスから参照した場合，ほとんどのプログラマはstatic finalなものと思うのではないでしょうか。

絶対に自分だけしか使わないのであれば良いですが(良くないけど)
そのクラスを使って何か作れ！といわれると，品質が信用できないです。

YKIDさんの書き込み (2002-12-10 15:48) より:
こんばんわ、YKIDです。

全てのフィールドがpublicであってもその理由が明記されていれば、別に危険とも思えません。（理由が薄弱な場合は除く）
逆に、無意味かつ闇雲にアクセサ（getter,setter）を作るほうが、品質を落とす原因になると思うのですが。

＃危険なコードとは、その意図や理由が第３者に伝わらないコードだと思いますよ。

悪夢を統べるものさんの書き込み (2002-12-10 13:17) より:
>まずデザインパターンは分析設計の分野です。決して実装の部分の概念ではありません。
これは同感．ただし，実装に密接に関係したものです．
設計というのは，本質的に実装と関係したものですから．
モデル化でさえそう．良いモデルを作成する際には実装まで考えて
モデル化します．それはJavaVM仕様書を見ればよく分かります．

>つまりそもそも分析設計が正常におこなわれていればそういうクラスが
>発生する事はありえません。
また，これなどは原因と結果が逆な気がする．
「そういう肥大化したクラスが発生する設計は悪い設計である」
「そういうクラスが発生しないように設計する」
だけであって，
「正しい設計をすれば，そういうクラスが発生しない」
というものじゃない．

>コード内容は分析設計では考慮しないものです。
>それは実装者が考慮する物ですからね。
こういう風に実装から乖離した設計は，意外に役に立たないもんです．

># しかし意外とオブジェクト指向という単語をしっていても
># その理論的背景を知っている人って少ないのでしょうか、、
理論的背景を知ってても，実際に役立たなければ意味がない．
結局は工学と理学の違いのようなもんじゃないですか．
＃別に理学を軽視しているわけじゃないので念のため．

YKIDさんの書き込み (2002-12-10 13:49) より:
で、私は、そうした用語の意味をあいまいなまま使ったり、そうしたあいまいな定義の用語を用いて説明するのは、齟齬を生みやすくするではないかと思うのです。

すべてのフィールドを public にすることは危険です。

その思い込みこそが危険ですよね
全てのフィールドがpublicであってもその理由が明記されていれば、別に危険とも思えません。

「属性（フィールド）」か「振る舞い（メソッド）」か、ということですが、私はメソッドこそ重要ではないかな、と思います。
クラスでは「カプセル化」と「抽象化」ということが言われます。
カプセル化というのは、皆さんの良く使うprivateってやつで、不正な値や矛盾した値が入らないようにする、つまりフィールドを外から触らせないこと。
抽象化というのは、例えば座標上の点を表すクラスがあるとしましょう。これはデカルト座標としても極座標としても値を得られるクラスだとします。
そのクラスを使う側からすれば、フィールドとしてデカルト座標で値を保持していようが極座標として保持していようが、両方を持っていて整合を取っていようが関係ないわけです。その値をfloatで保持していようがdoubleで保持していようが、二進化十進数で保持していようが、それも使う側では意識しなくて済みます。これが抽象化です。抽象的な「座標の点」のサービスを提供し、フィールドを外から意識させないことです。

H2さんの書き込み (2002-12-10 18:09) より:
ちょっと待ってください。属性と振る舞いが両方あってこそオブジェクトです。どういう意味で「フィールド」と言われているのかちょっと分かりませんが、privateにしてしまうから関係ないというのはおかしいと思います。そのオブジェクトがどのような属性を持っているのかは振る舞いを決めることと同じぐらいに大事です。

それから、「属性」と「振る舞い」しか話題が出ていませんので、「関係」というのも付け足しておきます。
#もっと白熱するかな

悪夢を統べるものさんの書き込み (2002-12-10 18:26) より:
>通称「憂鬱本」とよばれる以下の書籍を参考にしてください
>http://www.amazon.co.jp/exec/obidos/ASIN/4881356194/
よく見ると，UML，CASEツール，オブジェクト指向設計，C++．
おまけに悪名高き多重継承なんて章まである．．．．．
＃少なくとも，これから判断する限りでは，私ならこの本はお勧めしません．
Java，デザインパターン，リファクタリング，エクストリームプログラミング
という私とは，話が全然かみ合わない理由が分かった気がします．

sakitoさんの書き込み (2002-12-10 19:14) より:
何事にもバランスは大切だと思います。

sakitoさんの書き込み (2002-12-10 19:14) より:
いくつかの前にぼくは関係に関して言及してます。
操作により関係が構築されるという感じです。

Javaによりあった本としては
オブジェクト指向とコンポーネントによるソフトウェア工学
http://www.amazon.co.jp/exec/obidos/ASIN/4894712636/
ですが、あまり基礎的って感じではないですね。。
あわせて読むと適切かもしれません。

H2さんの書き込み (2002-12-10 21:12) より:

引用:
sakitoさんの書き込み (2002-12-10 19:14) より: 何事にもバランスは大切だと思います。

当たり前ですね。

H2さんの書き込み (2002-12-10 21:12) より:

引用:
sakitoさんの書き込み (2002-12-10 19:14) より: いくつかの前にぼくは関係に関して言及してます。 操作により関係が構築されるという感じです。

読みましたよ。でも、あまり重点を置いていなかったように受けましたし、「操作こそ関係」と書いてありましたので操作と関係を同じものとしていたのかなぁと思ったので前記の投稿をしました。

何となく違うなぁと思うのが、「操作により関係が構築される」や「属性にあわせてメソッドを作成する事はない」などの振る舞い(メソッド)がオブジェクトの中心であるという部分です。「関係があるから操作が必要」と言えるし、「この属性の操作のためにメソッドを作る(特にBeanのプロパティはそういう傾向があります)」というのもアリだと思います。もちろん極端な話をされているのは分かりますが、初めてオブジェクト指向を触った人が誤解すると困ります。

また、オブジェクト指向とはアイディオロジーであり、メソドロジーではありません。ですので、「これがオブジェクト指向においての正しいやり方だ！」という答えはないかと。悪夢を統べるものさんが取るデザインパターン・リファクタリングのような実装フェーズを頭に置いた開発過程でも、sakitoさんが言われるような分析・設計を重視した開発過程でもどちらでも良いのではないでしょうか。バランスと言うやつですね。
（個人的にはsakitoさんのような分析・設計を重視していますが。）

引用:
Javaによりあった本としては オブジェクト指向とコンポーネントによるソフトウェア工学 http://www.amazon.co.jp/exec/obidos/ASIN/4894712636/ ですが、あまり基礎的って感じではないですね。。 あわせて読むと適切かもしれません。

お勧めですか。メモメモ・・・。興味があるので早速読んでみたいと思います。感想はまた後ほど。