K.Maebashi's BBS 投稿フォーム

ハンドル名
件名
Link

>>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関係）が成り立つ。従って、同じふるまいを持つから
>> と言って、意味的に無関係なクラス間に継承関係を持たせるのは適切でない
>> 場合が多い。
>
>だそうですよ。

spamよけのため、ここに「ほげぴよ」と入力してください。

削除パスワード : クリック！