問題タブ [liskov-substitution-principle]

Liskov Substitution Principle (LSP) がオブジェクト指向設計の基本原則であると聞いたことがあります。それは何であり、その使用例は何ですか?

今日、C# でのインターフェイスの実装は、「Is-A」の関係ではなく、単なる「Can-Do」の関係であると誰かが私に言いました。これは、LSP (Liskov Substitution Principle) に対する私の長年の信念と矛盾します。私は常に、すべての継承は「Is-A」の関係であるべきだと考えています。

したがって、インターフェースの実装は単なる「できること」の関係です。「IHuman」と「IEngineer」というインターフェースがあり、「IHuman」と「IEngineer」を継承するクラス「Programmer」が1つあるとしたら？確かに、「プログラマー」は「IHuman」と「IEngineer」です。

単なる「Can-Do」関係であれば、IHuman として扱う場合と IEngineer として扱う場合で「Programmer」インスタンスの挙動が異なることは期待できないということでしょうか?

コードベースを確認したところ、次のパターンに似た継承構造が見つかりました。

でClass2、Method1スローしNotImplementedExceptionます。

質問：

• インターフェイスの継承について一般的にどう思いますか？
• リスコフの置換原則IBaseとの関係はありますか？Class2

次のようなクラスがあるとしましょう：

そして、拡張メソッドができることを超えて何かを追加するためにそれを拡張したい....私の唯一のオプションは構成です:

これは機能しますが、大変な作業です...しかし、まだ問題に遭遇します:

ここで Foo を渡すことはできますが、スーパー Foo を渡すことはできません。なぜなら、C# は SuperFoo が Liskov Substitution の意味で本当に資格があるとは考えていないためです...これは、構成による私の拡張クラスの使用が非常に限られていることを意味します。

したがって、これを修正する唯一の方法は、元の API 設計者がインターフェースを残しておいてくれることを願うことです。

これで、SuperFoo に IFoo を実装できます (SuperFoo は既に Foo を実装しているため、署名を変更するだけです)。

そして完璧な世界では、Foo を消費するメソッドは IFoo を消費します。

これで、C# は、共通のインターフェイスによって SuperFoo と Foo の関係を理解し​​、すべてがうまくいきました。

大きな問題は、.NET が、拡張すると便利な場合がある多くのクラスを封印し、通常は共通のインターフェイスを実装しないため、Foo を受け取る API メソッドが SuperFoo を受け入れず、オーバーロードを追加できないことです。 .

それで、そこにいるすべての作曲ファンのために....この制限をどのように回避しますか?

私が考えることができる唯一のことは、内部の Foo を公開して、時々渡すことができるようにすることですが、それは面倒です。

私が見る非常に一般的なパターン（この質問の時点でZend Frameworkを扱っていたという理由だけで、Zend Frameworkを選択しています）は、次のようなものです。

Zend_Formは抽象クラスではありませんが、それ自体で完全に使用できます。これは、フォームを素敵なクラスに「カプセル化」する場所として「推奨」されているようです。

これはリスコフの置換原則に違反しますか？Zend_Formの各サブクラスは、基本クラスとは大きく異なる動作をします。これにはコンポジションを使用する方が良いでしょうか、それとも私はこの原則を完全に誤解していますか？

私はデザインを始めたばかりで、デザインの原則を学んでいます。

長方形から正方形を導出することは、リスコフの置換原理に違反する典型的な例であると述べています。

その場合、正しい設計は何ですか？

私には2つのクラスがあります...ParcelとFundParcel...そしてサブタイプのIEnumerableをスーパータイプのIListに変換しようとしています...

これらは、次のようにメソッドの別のクラスで使用されます。

私が理解していないのは、foreachステートメントを次のように減らすことができない理由です。

基本的に「引数の種類」というエラーが表示されます'System.Colection.Generic.IEnumerable<FundParcel>' is not assignable to parameter type 'System.Collections.Generic.IEnumerable<Parcel>'"

しかし、そうだとすれば、なぜ小包を追加するのかわかりません...

メソッド全体を次の行に置き換える必要があるように感じます。

...または、サブタイプはスーパータイプの代わりに使用できる必要があるため、メソッドを完全に破棄することもできます。

この場合のAddRangeとの取引と、この場合にforループが必要になる理由を誰かが説明できますか？

System.ICloneable インターフェイスを継承する汎用インターフェイスを作成しようとしていますが、Clone() メソッドの returntype は T です。もちろん、T 型には System.Object クラスの継承であることを確認するための制約が必要ですが、次のコードは機能しません。

私は何を間違っていますか？

また、次の制約は機能しません。

1. ここで T : System.Object
2. T : クラス

この場合、この問題を解決するために、戻り値の型を絞り込むことができるという Liskov-principle をどのように使用できますか?

PS: 私の英語が間違っていたら申し訳ありません。私は英語のネイティブ スピーカーではありません。

私が何かを持っているなら

つまり、正方形と三角形のクラスを使用してはならず、図のみを参照する必要があるということですか？

決してこのようにしないように：

複合パターンのリーフは、リーフが使用することのない、、、およびメソッドを含むコンポーネントインターフェイスを実装しAddますRemove。GetChildこれは、インターフェイス分離の原則に違反しているようです。

では、Composite Pattern SOLIDの使用法はどうですか？

複合パターンへのリンク：http：//www.dofactory.com/Patterns/PatternComposite.aspx