kitajimaです。
随分と白熱していますね。
> 「OOPとはオブジェクトを中心にすえたプログラミング手法だ．」
> しかし「オブジェクトさえあればOOPか」というと，通常はそれは間違いです．
低レベルな例ですが、例えば関連のある複数クラスの複数の情報を一手に取得
してきて、あとは配列にぶち込むなり定数に切った値でfor文やif文の条件を
べたべた並べるなりして、すべてのアルゴリズムをすべて投入したメソッドを
書いてしまえば、その付近はダイヤモンドより硬い結束(結合度ともいう？)で
結ばれて、どんな仕様変更も跳ね除ける迫力を持つことになりますよね。
この例では、責務の分担も誤っています。
重要なのは二つ目の“O”であって、Objectで構成されていても、構成を考え
る段階で、処理なり機能なりの捉え方・見方が異なってしまえば、結果として
願わしくないObjectが「ある」だけで、OOPではないでしょうね。
> OOP:Object-Oriented Programming，オブジェクト指向プログラミング
> OOD:Object-Oriented Design，オブジェクト指向設計
> OOA:Object-Oriented Analysis．オブジェクト指向分析
どれも、オブジェクトを「指向」して対象をモデリングしているが、その「目
的・ポリシー」が異なるため、出来上がる設計図異なったり、会話がすれ違っ
てしまうのではないでしょうか。
「外部設計」「内部設計」「実装設計」って、トレーサビリティを保ちながら
も、全く異なる思想で作られますよね。
要求を整理するための設計から始まって、やがてアーキテクチャ・フレームワ
ークの制限が反映された設計で改編されて、さらに実装言語の特徴を反映した
設計が進められて…という風に、それぞれのフェーズで、設計の目的(レビュ
ーの対象も)が違うのですから、それぞれの設計が別のフェーズで「使える」
ってことは、考え難くて当然ではないでしょうか。
> 「カプセル化，継承，ポリモフィズム」
> こういうOOPの三本柱さえOOA/OODには満足にありません．
ない訳ではないですよね。オブジェクト指向ですから。「満足に」という点が
ポイントなのでしたら、私にはその境界が分かりませんので答えられませんが。
OOP程厳密ではない、という意味でしたら、それはOOA/OODでは厳密には要求さ
れないからかも知れません。
例えば継承ですが、
共通の性質を基底クラスの、異なる部分は複数の子クラスの属性・振る舞いと
して捉えるのか、それとも異なる部分はインスタンス変数であってそもそもは
一つのクラスで表せると捉えるのかは、分析段階では明確ではない(この段階
で拘束してしまうべきではない)こともあります。分析段階ではドメインの本
質を把握することが目的だからです。
そういう設計図が回ってきて、実装段階では「ここは継承しないと実現できな
いぞ！」ということはあると思います。
・・・
そういう場合は、設計を変えればいいと思います。（トレーサビリティは保た
ないといけませんが。）但し、実装が正しいかどうかは、分析レベルの設計で
検証されることになりますが。
結局、相互補完されるものであって、どれが誤りというものではないのでは、
というのが結論です。
#すみません、もう眠たくなってしましました。