K.Maebashi's BBS

kit さんへのまとめ。 俺は当初、kit さんは「オブジェクトの is-a など問題にしなくてよい。LSP のみが確かな判断基準となる」と言っているのだと思っていました。 理由は、 > 設計手順としては、まず常識的な is-a を使って継承関係を考えてみた > 上で、それを LSP で検証すればいいんですよ。検証に通らない場合には、 > たとえ常識的なis-a 関係であっても、継承関係にはしません。検証に通 > れば、もちろん継承関係にします。 これを [715] まで言わなかったことです。 しかし、実態は上記の通り、kit さんも、LSP を適用する前に、オブジェクトの is-a での判断を行っています。 そして、俺が [722] で書いた > 結局、この文献は「どんなものを継承関係にすべきか」という指針には、一言も言及していないのです（「どんなものを継承関係にしてはいけないか」は、LSP を用いて言及しています。＜以下略＞）。 これは、kit さんにも当てはまります。 上記の [715] の文章は、まさにこれだからです。 LSP で検証したことによって、最初に下した「常識的な判断」が正解だったか間違いだったかは確かに分かりますが、その「常識的な判断」は LSP を用いて下したものではありません。 kit さんも、「どんなものを継承関係にするのが正解か」は、LSP を用いて判断していないのです（判断しているのは「結果的に正解だったか」です）。 > これも繰り返しになりますが、「照らすまでもなく」のような暗黙の知識は、 > 法則としては役に立たないんですよ。 「照らすまでもなく間違いと分かる」のは「まるで神に囁かれたかのごとく、なんとなくわかる」のではありませんよ。「LSP など適用しなくても、分析をしっかりとやることによって、きちんと根拠付けて導かれる」のです。 もっとも、kit さんが求める「分析というステップをすっ飛ばして、『LSP に照らすまでもなく』正解が分かる、設計のお手本」から見れば、これでさえ暗黙的に見えるかもしれませんけれど。 kit さんの求めるものとは、「多くの場合に適用できる（が、たまには失敗することもある）、常識的な設計パターン」さえ超越した、「常に成功を約束された設計パターン」なのでしょう。すなわち、「あるクラスＡは、どのような案件であるかによらず、常に、他のクラスの子クラスではないか、あるいは、Ｂの子クラスであるかのどちらかである」という保証（と、ＡとＢの一対一の対応表）ですね。なぜなら、kit さんは「案件によって、Ａの親はＢが適切な場合も、Ｃが適切な場合もある。それは案件を分析してみるまで分からない」というのではダメだとおっしゃるからです。 そのようなパターンが本当に存在するのなら、それは素晴らしいことでしょう。 しかし、もしそれを実践したとすると、失敗するケースの方が多いように思えてなりません。 > むしろこういう説明は、 > この説明に沿って機械的に作業していけば、「オブジェクト指向設計」ができるんだ。 > という印象を与えかねないという点で有害だと思います。 > 確かに、ソフト屋は常に一定以上の品質のプログラムを供給しなければならないものであり、その意味では、「機械的にやっていけば誰でもちゃんとした設計ができる」という手法があるのならば大変結構なことです。しかし、残念ながら、オブジェクト指向設計はそこまでいっていないと私は思っています ※4。 > ていうか正直私は、こういうことは、未来永劫、決して「機械的にできる」ようにはならないと思います。 「疑り深いあなたのためのオブジェクト指向再入門／なぜわからなくなってしまうのか?」より抜粋。 わかってらっしゃるじゃないですか。