問題タブ [liskov-substitution-principle]

LSP とその違反の概要を理解できました。たとえば、setWidth() および setHeight() 関数を持つ Rectangle を正方形で拡張することは、追加の要件があるため、LSP の微妙な違反です。同様に、関数 something(Grass g) で Duck クラスを拡張する GreenDuck には、草が緑であることを要求する余分な節があってはなりません。

正方形と長方形のシナリオでは、多角形インターフェイスと、長方形と多角形を独自の方法で実装する正方形クラスを実装するのが正しいと思います。GreenDuck シナリオでは、コンポジションを使用して Duck をフィールドの 1 つとして持つ GreenDuck は良い考えかもしれません。

Q1) 上記の 2 つのシナリオについて、私の理解は正しいですか?

Q2) また、LSP が「拡張」を許可するシナリオをモデル化することができないため、質問に至りました。誰かが LSP を掘り下げて、extend が適切であり、構成がそれほど良くない場合にボーナスとなる特定の例を提供できますか?

編集：明確にするために

現在、コード コントラクトでは、メンバーが基本クラスで既に前提条件が設定されている派生クラスのメンバーの前提条件を許可していません (現在、エラーではなく警告が表示されます)。この背後にあるロジックがわかりません。派生クラスは、親が期待される場所で常に使用できるようにする必要があるという Liskov の置換規則に関係していることを理解しています。もちろん、「使用済み」とは、期待どおりに動作することを意味します。インターフェイスを実装するさまざまなタイプは状態を追加しないため、契約を正確に義務付けることができるため、これはインターフェイスにとって問題ないように思えます。ただし、基本クラスから継承する場合は、状態と特別な機能を追加するためにそうしているため、オーバーライドするメソッドには追加の要件が必要になることがよくあります。どうして」

以下をご覧ください。

このクラス階層はリスコフのルールに違反していると主張するかもしれませんSpeaker. しかし、それがコード コントラクトを使用する理由ではありませんか? 要件が満たされていることを確認するには？

私は C++ クラスの継承を使用して Liskov Substitution Principle の違反を試みていましたが、Java プログラムで示された LSP 違反に起因する同じ問題を再現できませんでした。Java プログラムのソースは、このページにあります。この違反により、ページに記載されているエラーが発生します。そのコードを C++ に翻訳したものを次に示します。

Rectangle クラスの予想通り、答えは 50 でした。Java の私の翻訳は間違っていますか、それとも Java と C++ のクラスの実装の違いに関係していますか? 私が持っている質問は次のとおりです。

1. この動作の違いの原因は何ですか (内部/コードの問題)?
2. Java の LSP 違反の例を C++ で複製できますか? もしそうなら、どのように？

ありがとう！

私はOOPの初心者です。最近、リスコフの置換原理について読みました。

以下のコードでは、SquareクラスがGive_Areaを継承しています。Squareクラスに正方形に関連する何かがあるとします (有効性チェックなど)。Give_Areaは、正方形の面積 (4 つの頂点が円の周囲にある) と円の面積を与えます。したがって、Radiusが与えられた場合、円と正方形の領域を印刷する必要があります (その円の周囲に配置された頂点で構成されます)。円の面積を取得するために、パラメーターを使用しました。ただし、正方形の面積を取得する際のパラメーターはありません。したがって、ここでオーバーロードを行いました。

私の質問は..

このコードが違反している場合、Liskov Substitution Principle に違反しないオーバーロードの例を教えてください。

クエリをグーグル検索しましたが、何も見つかりませんでした。:(

前もって感謝します。

vara がサブクラスでa をオーバーライドできない理由、valおよびその逆ができない理由は理解していますが、Scaladefがサブクラスで avarをスーパークラスでオーバーライドできない理由を理解できません。

変更可能であるため、 a がそれをオーバーライドvarできないのはなぜですか? def誰でもこれを理解するのを手伝ってもらえますか?

私はこのようなインターフェースを持っています

デバイス間の互換性を確認できるように、すべてのクラスで上記のインターフェイスがサポートされている必要があります。そのために、上記の IVersion クラスから各デバイスをパブリックに継承します。

IVersion (および Liskov Substitution Principle) から継承しているため、デバイスがバージョンであることを意味します。しかし、私が望む実際の関係は、デバイスにバージョンがあるということです。

IVersion のようにすべてのデバイスでメソッドをサポートしたいのですが、私が行った方法は正しくないと思います。誰かがより良い方法を提案できますか? コンポジションを使用できますが、IVersion のメソッドをデバイスの基本クラスに追加し、内部で IDevice 実装を使用する必要があります。これは私が達成したいことをするための最良の方法ですか?

誰かが拒否された遺贈の意味を説明してもらえますか? 私はいくつかの記事を読んでみましたが、それは一種のコードの匂いであるか、wiki では、基本クラスのコントラクトが派生クラスによって尊重されないように、基本クラスのメソッドをオーバーライドするクラスであることがわかります。

しかし、一言で言えば、またはより簡単な言葉で言えば、それは実際には何ですか?