Liskov Substitution Principle（LSP）は、オブジェクト指向設計（OOD）において重要かつ一般的なものです。LiskovSubstitution Principleの知識ポイントを要約してみましょう。
- ウィキペディアの定義
オブジェクト指向プログラミングでは、リスコフ置換の原則はサブタイプの特別な定義です。これは、1987年の会議での「データの抽象化と階層」というタイトルのスピーチで、Barbara Liskovによって最初に提案されました。
リスコフの代替原則の内容は、「派生クラス（サブクラス）オブジェクトはプログラム内の基本クラス（スーパークラス）オブジェクトを置き換えることができます。」上記の内容は、リスコフの元のテキストではなく、ロバートマーティンから翻訳されたものです。 （ロバート・マーティン）原文の解釈。元のテキストは次のとおりです。
Barbara LiskovとJeannette Wingは1994年に論文を発表し、上記のLiskov置換原理を提案しました。
SOLID-「SOLID」のLは、リスコフ置換原理を指します。
定義1：タイプT1のすべてのオブジェクトo1に対して、タイプT2のオブジェクトo2がある場合、T1によって定義されたすべてのオブジェクトPがすべてのオブジェクトo1によってo2に置き換えられても、プログラムPの動作は変化しません。 、タイプT2はタイプT1のサブタイプです。
定義2：基本クラスへのすべての参照は、そのサブクラスのオブジェクトを透過的に使用できる必要があります。
Liskov Substitution Principle（LSP）：基本クラス（親クラス）へのすべての参照は、そのサブクラスのオブジェクトを透過的に使用できる必要があります。
Liskov Substitution Principleは、上方変換は安全である（つまり、サブクラスオブジェクトはスーパークラスオブジェクトに変換される）と述べています。多態性は、型の安全性を保証するという前提の下でのみ達成できます。
「リスコフ置換原則では、上方変換は安全であり（つまり、サブクラスオブジェクトはスーパークラスオブジェクトに変換される）、多型性は型の安全性を保証するという前提の下でのみ達成できると述べています。」劉先生は非常に正確に言った。置換の原則には多型が含まれており、リヒターの置換の原則に基づいてより優れた多型を設計できます。
私の意見を述べさせてください。作者は、反転イメージが多すぎると、インターフェースプログラミングに向けられた反転の原則に依存していると述べました。6つの設計原則が相互に関連しているため、リヒターの置換の原則は、継承の定義を明確に述べていると思います。絶対にインターフェース指向プログラミングであってはなりません。共通性ではなく、リヒター原理と他のいくつかの原理の違いを説明する必要があります。
具体的には、ポリモーフィズムはオブジェクト指向のメカニズム（オブジェクト指向の3つの主要な機能の1つ）であり、静的なポリモーフィズム（関数のオーバーロード）と動的なポリモーフィズム（関数のカバレッジ、または動的なバインディング）が含まれます。動的なポリモーフィズムを指します。つまり、プログラムの実行中に、サブクラスオブジェクトの動作（メソッド）が親クラスオブジェクトの動作（メソッド）をオーバーライドできます。Liskov Substitution Principle（LSP）は、オブジェクト指向の設計原則です。サブクラスオブジェクトは、親クラスが使用される場所であればどこでも使用できます。これにより、開始および終了の原則の実装の基礎が築かれ、親クラスのプログラミングが可能になります。実行時に、使用するサブクラスオブジェクトを決定します。これにより、システムのスケーラビリティとメンテナンス性が向上します。Liskov置換の原則では、実際にはポリモーフィックメカニズムが使用され、サブクラスオブジェクトが親クラスオブジェクトをオーバーライドすると、親クラスの動作がポリモーフィズムによって上書きされます。
Liskov Substitution Principleによれば、ソフトウェアでは、基本クラスオブジェクトがそのサブクラスオブジェクトで置き換えられ、プログラムはエラーや例外を生成せず、その逆は当てはまりません。ソフトウェアエンティティがサブクラスオブジェクトを使用する場合つまり、基本クラスのオブジェクトを使用できるとは限りません。例：私は動物が好きで、犬は動物のサブクラスなので、犬が好きですが、犬が好きです。動物でもありますが、マウスは好きではないので、私は動物が好きだとは言えません。
たとえば、2つのクラスがあり、1つはBaseClass、もう1つはSubClassクラス、SubClassクラスはBaseClassクラスのサブクラスである場合、メソッドがBaseClassタイプの基本クラスオブジェクトBaseを受け入れることができる場合、次のようになります。method1（base）、次に、BaseClassタイプのサブクラスオブジェクトsubを受け入れる必要があります。method1（sub）は正常に実行できます。逆の置換は適用されません。たとえば、メソッドmethod2は、BaseClassタイプのサブクラスオブジェクトsubをパラメーターとして受け入れます。method2（sub）の場合、オーバーロードされたメソッドでない限り、通常method2（base）はありません。
Leeb置換の原則は、開閉の原則を実現する重要な方法の1つです。サブクラスオブジェクトは、基本クラスオブジェクトが使用される場所であればどこでも使用できるため、基本クラスタイプを使用してプログラムでオブジェクトを定義し、実行時に再実行してください。そのサブクラスタイプを決定し、親クラスオブジェクトをサブクラスオブジェクトで置き換えます。
基本クラス型を使用してプログラムでオブジェクトを定義し、実行時にそのサブクラス型を決定して、親クラスオブジェクトをサブクラスオブジェクトで置き換えます
こんな感じで、親クラスの利便性が実装されていますサブクラスはなるべく書き換えないでくださいサブクラスは親クラスに実装されていないメソッドを実装できますか？
仮想メソッドの書き換えのみがポリモーフィックであり、非仮想メソッドの書き換えはインターフェイス指向プログラミングにとってほとんど意味がないため、リヒターの原理を理解することで、インターフェイス指向プログラミングについて考えることができます...
JAVAでは、ポリモーフィズムはリスコフ置換原則に違反しますか？？
Liskov置換原則では、親クラスメソッドのオーバーライドを回避するためにサブクラスが必要ですが、ポリモーフィズムの条件の1つは、サブクラスが親クラスメソッドをオーバーライドすることを要求することです。そのため、リスコフの代入原理、継承、多態性の関係がわかりません。偉大な神に答えてもらい、お辞儀を始めましょう。
LSPの元の定義はより複雑ですが、Liskov代入原理の一般的な解釈では、サブクラスオブジェクトは親クラスオブジェクトを置き換えることができ、プログラムロジックは変更されません。リープ置換の原則には、少なくとも次の2つの意味があります。
Leeb置換の原則は継承です。継承がコードの再利用、つまり共有メソッドの場合、共有親クラスのメソッドは変更せず、サブクラスで再定義できません。サブクラスは、新しいメソッドを追加することによってのみ関数を拡張できます。親クラスとサブクラスの両方をインスタンス化でき、サブクラスの継承メソッドは親クラスと同じです。親クラスがメソッドを呼び出す場合、サブクラスも同じ継承を呼び出すことができます論理的な方法は親クラスと同じですが、親クラスのオブジェクトをサブクラスのオブジェクトに置き換えた場合は、当然、ロジックに一貫性があり問題ありません。
継承の目的がポリモーフィズムであり、ポリモーフィズムの前提がサブクラスが親クラスのメソッドをオーバーライドして再定義することである場合、LSPに準拠するには、親クラスを抽象クラスとして定義し、サブクラスに再定義させる抽象メソッドを定義する必要がありますこれらのメソッドは、親クラスが抽象クラスの場合、親クラスをインスタンス化できないため、プログラム内にインスタンス化可能な親クラスオブジェクトはありません。ロジックに一貫性がない場合、サブクラスが親クラスインスタンスを置き換える可能性はありません（親クラスインスタンスはまったくありません）。
LSPに適合しない最も一般的な状況は、親クラスと子クラスの両方がインスタンス化可能な非抽象クラスであり、親クラスのメソッドが子クラスによって再定義されている場合です。このクラスの実装の継承により、親クラスと子クラスに違いが生じます。強い結合、つまり、実際には関連のないプロパティとメソッドが強制されるという事実は、プログラムの拡張と保守に役立ちません。
LSPに準拠するには？文を要約すると、インスタンス化可能な親クラスから継承しないで、抽象クラスとインターフェイスに基づく継承を使用するようにしてください。
それは非常に徹底的です。端的に言えば、誰もが具体的ではなく、抽象化に基づいてプログラミングしています。これは達成することもできます：（抽象化に基づいて）拡張にオープンであり、（具象に基づいて）変更を禁止します。
Liskov変換の原則では、サブクラスが具象継承ではなく抽象から継承する必要があります。抽象化から継承する場合、サブクラスはスーパークラスメソッドをオーバーライドする必要があります。したがって、リヒタースケールの原理と多態性は相補的です。最初に言った記事は聞いたことがありません。
ちょうど今いくつかの記事を読んだ後、著者はリスコフ変換の原則は親クラスの非抽象メソッドの書き換えを避けるべきであり、ポリモーフィック実装は抽象メソッドの書き換えによって実現されるため、競合は発生しないと述べました。
リスコフ置換の多態性に違反しないでください：親クラスの抽象メソッドを書き換えます
核となる考え方は、サブクラスはその基本クラスを置き換えることができなければならないということです。この考え方は、継承メカニズムの制約に反映されています。システムが、サブクラスが基本クラスを置き換えることができる場合にのみ、システムは、実行時にシステムがサブクラスを確実に認識できるようにします。親クラスと子クラスの特定の振る舞いでは、継承階層の関係や特徴を厳密に把握し、基底クラスを子クラスに置き換えればプログラムの振る舞いは変わらない。同時に、この制約は逆には当てはまりません。サブクラスは基本クラスを置き換えることができますが、基本クラスは必ずしもサブクラスを置き換えるわけではありません。
リスコフの代替原則は、継承の抽象化と多態性の基礎に主に焦点を当てているため、リスコフの代替原則に従うことによってのみ、継承の再利用を確実に保証できます。実装方法はインターフェイス指向プログラミングです。パブリック部分は基本クラスインターフェイスまたは抽象クラスとして抽象化され、Extract Abstract Classを介して、同じ責任をサポートするように親クラスをオーバーライドすることにより、サブクラスに新しいメソッドが実装されます。
リスコフの代替原則は、継承メカニズムの設計原則であり、リスコフの代替原則に違反すると、必然的にオープンおよびクローズの原則に違反します。
Liskov置換の原則により、システムのスケーラビリティが確保されると同時に、ポリモーフィズムに基づく抽象化メカニズムが実装されます。これにより、コードの冗長性が削減され、実行時の型の識別が回避されます。
