>CESさんいわく
>
>>「is-a である関係が、LSP を満たすように作れ」と言っているのです。
>
>それじゃあ「CESさん言うところのis-a」がLSPを満たすのは当たり前ですわな。
>そう定義したんだから。
「LSP を満たす関係が is-a である」とは言っていませんよ（そう言っているのは kit さんです）。
結果的にはそうなりますが、それは is-a の定義ではありません。
じゃあ is-a の定義は何なんだって話になりますが、言い換える言葉が見つかりませんね。is-a は is-a です。「Ａ is-a Ｂ」は「ＡはＢの一種」です。これがもっともシンプルかつ的確ではないですか。
以前に、ソフトウェアは「分析→設計→実装」の３段階で作られると言う話をしました。
俺の言う「is-a」の関係を決めるのは分析段階、LSP を満たすように作るのは設計段階の話です。
それで設計段階になって、LSP がどうしても満たせなくなったらどうするか？
LSP を捻じ曲げて is-a を固持しろなんていってません。分析からやり直すのです。
ちょっと古い投稿を引用すが…
[658]
> 設計を見直す＝分析のしなおし、だよん。って。
その通りではないですか。
あるプロジェクトに直面した時、「ＡはＢの一種である」とも「ＡはＢの一種ではない」とも、どちらの考え方もできます。
どちらが適切なのかを選ぶのが「分析」というプロセスですよ。
>我々は、設計段階で、どういう継承関係にすればうまくいくかを知りたい
>ため、設計原則を求めているわけです。
そこで機械的に従えばいいガイドラインを求めるのは、分析プロセスの放棄ですよ。
>>１：オブジェクトが is-a であると仮定した。
>>２：LSP に照らし合わせたらうまく行かなかった。
>> （照らし合わせるまでも無く判断できる場合もある）
>>３：実はオブジェクトは is-a じゃなかったんだ。だから継承関係にはしない。
>
>こちらも同様です。is-aの定義が「うまくいくかどうか」で決定されるんなら、
>「うまくいくようにやりなさい」と言ってるだけのことで、結局何も言って
>いないのです。
そうですよ。
「どうすればうまく行くのか」は、その場合に応じて変わるのですから、それ以外に言いようが無いではありませんか。
こんな記事見つけました（Wikipedia - 「継承」）
http://ja.wikipedia.org/wiki/%E7%B6%99%E6%89%BF
> 一般的に、AがBを継承する場合、A is a B. （AはBの一種である）という
> 意味的な関係（is-a関係）が成り立つ。従って、同じふるまいを持つから
> と言って、意味的に無関係なクラス間に継承関係を持たせるのは適切でない
> 場合が多い。
だそうですよ。