問題タブ [liskov-substitution-principle]

リスコフの置換原則についての私の理解は、真である基本クラスのいくつかのプロパティ、または基本クラスの実装された動作は、派生クラスでも真である必要があるということです。

これは、メソッドが基本クラスで定義されている場合、派生クラスでオーバーライドしてはならないことを意味すると思います。派生クラスの代わりに基本クラスを置き換えると、異なる結果が得られるためです。これはまた、（純粋でない）仮想メソッドを持つことは悪いことだと思いますか？

原理の理解が間違っているのではないかと思います。そうしないと、なぜこの原則が良い習慣であるのか理解できません。誰かが私にこれを説明できますか？ありがとう

大まかに言えば、Liskov Substitution Principle は、ユーザーに影響を与えることなく、派生クラスを基本クラスの代わりに使用できると述べています。基本クラスが抽象クラスの場合、つまり基本クラスのインスタンスを使用しているユーザーがいない場合、Liskov の継承制限は派生クラスにも適用されますか?

私はオブジェクト指向プログラミング言語のクラスのいくつかのスライドを読んでいて、タイプ-サブタイプの定義に足を踏み入れました：

Barbara Liskov、「データの抽象化と階層」、SIGPLAN Notices、23、5（1988年5月）：

ここで必要なのは、次の置換プロパティのようなものです。タイプSのオブジェクトo_sごとに、タイプTのオブジェクトo_Tがあり
、Tに関して定義されたすべてのプログラムPに対して、o_Sが置換されてもPの動作は変わりません。 o_Tの場合、SはTのサブタイプです

次に、例を示します。

Point = {x：Integer、y：Integer}
PositivePoint = {x：Positive、y：Positive}
ここで、Positive = {k：Integer | k>0}

PositivePoint≤Pointと言えますか？

はい。PositivePointタイプの要素は、Point用語で定義されたプログラムのPointタイプの要素を常に置き換える可能性があるためです。

さて...私にとっては、まったく逆のはずです。負の座標を持つPointを使用するプログラムではPositivePointを使用できなかったのに対し、Point≤PositivePointは逆にできたためです。

構文がまたはであるかどうかは疑問でしType ≤ Sub-typeたSub-Type ≤ Typeが、ステートメントはより明確に見えます。それでは、何が問題になっていますか？

編集

物事を簡単にするために、質問は次のとおりです。それPositivePointはのサブタイプであると言えPointますか？なんで？

2回目の編集

私がコメントに書いたことをここに報告します。それが私の問題をより明確にすることを願っています。

プログラムがPoint（-100、-100）からPoint（100、100）までの正方形のマップを描画する必要があるとします。タイプを使用するとどうなります PositivePointか？プログラムの動作は変わりませんか？そうではありません。この「変わらない振る舞い」は私が得られない唯一のものです。サブタイプの定義が単にinheriting and overriding他のタイプからのものである場合、それは問題ありませんが、そうではないようです。

仮想メソッドの使用はLSP （ SOLID原則のL部分）に違反しますか、それともいくつかの例外がありますか？

よろしくお願いします、Saghar Ayyaz

私は初めて Robert Martin の SOLID 設計原則に固執しようとしていますが、それが苦手です。

本質的に、「ノード」オブジェクトの階層が必要です。一部のノードは NodeHosts、一部は NodeChildren、一部は Both です。誰もがこれを以前に行ったことがありますが、設計を過度に複雑にしたり、ノードのサブタイプで次のようなことをしたりせずに、SOLID で行う方法がわかりません。

これはリスコフの置換原理に違反していますよね？より良い方法は何ですか？これが私が今持っているものです。

私は今夜​​、ワードのwikiでリスコフの置換原則の元の声明に出くわしました。

ここで必要なのは、次の置換プロパティのようなものです。タイプSのオブジェクトo1ごとに、タイプTのオブジェクトo2があり、Tに関して定義されたすべてのプログラムPに対して、o1が置換されたときのPの動作は変更されません。 o2の場合、SはTのサブタイプです。」-Barbara Liskov、Data Abstraction and Hierarchy、SIGPLAN Notices、23、5（1988年5月）。

私は常に述語論理の解析に夢中になっているので（最初はCalc IVに失敗しました）、上記がどのように変換されるかを理解しています。

基本クラスへのポインタまたは参照を使用する関数は、それを知らなくても派生クラスのオブジェクトを使用できる必要があります。

私が理解していないのは、Liskovが説明するプロパティが、SがTのサブタイプであり、その逆ではないことを意味している理由です。

たぶん私はまだOOPについて十分に知らないのですが、なぜLiskovのステートメントは可能性S-> Tのみを許可し、T-> Sを許可しないのですか？

ReadOnlyCollectionクラスの仕様を見ると、 IListインターフェイスが実装されています。

IList インターフェイスには Add/Update/Read メソッドがあり、これをインターフェイスの事前条件と呼びます。IList があれば、アプリケーションのどこでも、この種の操作をすべて実行できるはずです。

しかし、コードのどこかで ReadOnlyCollection を返し、.Add(...) メソッドを呼び出そうとしたらどうなるでしょうか。NotSupportedException をスローします。これは悪いデザインの良い例だと思いますか? さらに、このクラスはLiskov Substitution Principleを破っていますか?

Microsoft がこのように実装したのはなぜですか? この ReadOnlyCollection が IEnumerable インターフェイスのみを実装するようにする方が簡単 (かつより良い) でしょうか (ちなみに、これは既に読み取り専用です)。

LSPと共変性と反変性の関係は何ですか？何か関係はありますか？LSPは共分散の一形態ですか？

ユース ケース: データ テンプレートを使用して、View を ViewModel に一致させています。データ テンプレートは、提供された具象型の最も派生した型を検査することで機能し、それが提供するインターフェイスを調べないため、インターフェイスなしでこれを行う必要があります。

ここでは例を簡略化し、NotifyPropertyChanged などを除外していますが、現実の世界では、View は Text プロパティにバインドされます。簡単にするために、TextBlock を持つ View は ReadOnlyText にバインドし、TextBox を持つ View は WritableText にバインドするとします。

OnTextSet をオーバーライドしてその動作を変更すると、LSPに違反しますか? もしそうなら、それを行うためのより良い方法は何ですか?

リスコフの置換原則（SOLIDの「L」）を、原則のすべての側面を簡略化した方法でカバーする優れたC＃の例で説明できますか？それが本当に可能なら。