リヒターソフトウェアのデザインパターンの置換原則（PHP言語）の6つの原則

転載、元のリンクhttps://www.cnblogs.com/zhanghengscnc/p/8299459.html

私は疑問に満ちの原則の名のために、この原則を見て、同じ時間で多くの人々を確認してください。実際には、その理由は、この原則は、最初のMIT某さんレーン（バーバラ・リスコフ）によって提示され、1988年に記載されたということです来ます。

定義1：T1 O1のそれぞれのオブジェクトタイプ、O2 T2は、オブジェクトタイプを持っている、すべての世代が置換されるときに、すべてがO1、O2オブジェクトP T1・プログラムを定義した、プログラムがPの動作を変更しないようであれば、その後型がタイプT2 T1のサブタイプです。

定義2：基底クラスへのすべての参照は、透過的にそのサブクラスのオブジェクトを使用する必要があります。

問題の起源：P1の関数、クラスAによって完成関数はPがP1とP2組成新機能の本来の機能であるP、に展開された後にP1は、今機能を拡張する必要があります。クラスAのP Bサブクラスによって行わ新しい機能、Bは、元の関数P1の故障につながる可能性があり、P2の完了の新機能のサブクラスです。

ソリューション：継承を使用する場合は、リヒターの置換原則に従ってください。クラスは、クラスBは、親クラスAをオーバーライドして、親クラスAをオーバーロードしないようにしようしないように、外P2を完了するために、新しい機能を追加する新しい方法に加えて、時間を継承します

継承は、意味のこの層含まれています（抽象メソッドに対して）良い方法を達成している親クラスをすべてのサブクラスは、これらを遵守しなければならないことは必須ではありませんが、それは、実際には、設定された規範や契約のシリーズですこれらのサブクラスの非抽象メソッドのいずれかが変更された場合、契約は、しかし、それは全体の継承階層への損傷の原因となります。リヒターの置換原則は意味のこの層の表現です。

3のいずれかのようなプログラミングに大きな利便性で、対象物の特性を継承するだけでなく、それは不利益をもたらします。このクラスを変更する必要がある場合クラスは他のクラスに継承される場合、例えば、継承の使用は、オブジェクト間の結合を増加させる、侵襲的処置、低減移植手順をもたらす、その後、それを考慮にすべてのサブを取る必要がありますクラス、スーパーおよび修正は、すべての参照が誤動作する可能性があり、機能サブクラスにあります。

継承されたリスクの例としては、我々は責任があると、クラスAから番号2の減算機能を完了する必要があります。

クラス計算
{ 
    パブリック関数func1の（int型$ A、int型$ B）
    { 
        返す$ - $ B; 
    } 
} 

$サブ=新しい計算（）。
"100-50 ="エコー。$サブ>関数func1（100、50）; // 100-50 = 50は
"100-80 ="エコー。$サブ>関数func1（100、80）; // 100-80 = 20

その後、私たちは、新しい機能を追加する必要があります。一緒に2つの数の完了をした後、100合計とクラスBに責任があるとすなわち、クラスBの完全な二つの機能：

2つの数値を減算します。
2つの数値を追加し、100を追加します。

クラスAは、第一の機能を実現しているので、クラスBは、以下のように第二の機能のみ、それを完了する必要があり、クラスAを継承します。

クラス計算
{ 
    パブリック 関数 func1の（int型$ A、int型$ B ）
    { 
        返す $ - $ B ; 
    } 
} 

クラスその他延び計算
{ 
    パブリック 関数 func1のを（INT $ A、INT $ B ）
    { 
        戻り $ A + $ B 。
    } 

    パブリック 関数 func2のは（INT $ A、INT $ B ）
    { 
        返す $この - >関数func1（$、$ bの）+ 100 ; 
    } 
} 

$ 0 = 新しいその他（）。
エコー "100-50 ="。$ O - >関数func1（100、50）。// 100-50 = 150は、
エコー "100-80 ="。$ O - >関数func1（100、80）; // 100-80 = 180は
エコー "100 + 20 + 100 ="。$ O - >関数func2（100、20）。// 100 + 20 + 100 = 220

私たちは、減算エラーの正常な動作の本来の機能が発生していることがわかりました。その理由は、不注意差分法のすべての操作機能が得られ、親クラスのメソッドをオーバーライドという名前のメソッドへのクラスBは、元の実行の正常な機能のエラーになり、すべてのクラスB書き換えられた後に呼び出されたときが発生したことです。本実施形態では、基準関数は、サブクラスBに、基底クラスAによって行われる、異常が発生しました。実際のプログラミングでは、私たちはしばしば、親クラスを書き換えるシンプルでアップ書き込むために、新たな機能の手段によって達成ますが、継承された再利用のシステム全体は、比較的低いマルチステートプログラムの、特に頻繁に使用されますエラーのチャンスを実行することは非常に大きいです。親クラスはメソッドをオーバーライドする必要がある場合は、より一般的な方法は次のとおりです。元の親クラスとサブクラスは、より人気のある基底クラスの継承を継承し、オリジナルを削除し、代わりに組み合わせ関係の依存性、重合を、使用しています。

リヒター置換原理は人気の条件です：サブクラスは、親クラスの機能を拡張することができますが、元の関数の親クラスを変更することはできません。これは、次の4つの層の意味が含まれています。

サブクラスは抽象親クラスを実装することができるが、非抽象親クラスをカバーすることができません。
サブクラスは、独自のユニークな方法を追加することができます。
親クラスのサブクラスのメソッドがオーバーロードされた場合、プロセスの前提条件よりリラックスした親クラスのメソッドよりも（すなわち、プロセスパラメータ）の入力パラメータ。
抽象親クラスの実装のサブクラスは、方法の事後条件（すなわち、値を返す）親より厳しい場合。

我々はプログラミングで自分自身を見つけるので、それは多くの場合、プログラムはまだ良いを実行している、リヒターの置換原則に違反し、信じられないほどに見えます。私はリヒターは置き換えの結果がどうなるかの原則に従うことを持っていない場合ので、私たちは、この質問を持っているのだろうか？

結果は次のとおりです。コードの問題を記述するチャンスが大幅に増加されます。

リヒターソフトウェアのデザインパターンの置換原則（PHP言語）の6つの原則

おすすめ