事前条件の強化と事後条件の弱化は、リスコフ代替原理にどのように違反しますか？

次の場合、リスコフの置換原則に違反していると読みました。

1. 前提条件が強化されている、または

2. 事後条件が弱体化

しかし、これらの2つの点がリスコフの代替原則にどのように違反するかは、まだ完全にはわかりません。例を挙げて説明してください。具体的には、上記の条件のいずれかが、サブクラスオブジェクトをスーパークラスオブジェクトに置き換えることができない状況をどのように引き起こしますか？

1. ベースクラスがメンバーintで機能すると仮定します。現在、サブタイプでは、intが正である必要があります。これは前提条件が強化され、負の整数で以前は完全に正常に動作していたすべてのコードが壊れています。

2. 同様に、同じシナリオを想定しますが、基本クラスは、メンバーが呼び出された後にポジティブになることを保証するために使用されます。次に、サブタイプは、負の整数を許可するように動作を変更します。オブジェクトで機能する（および事後条件が正の整数であると想定する）コードは、事後条件が維持されないため、現在壊れています。

これらはもちろん些細な例ですが、概念は保持されます。ファイル/データベース接続を開いたままにしておくようなものは、問題につながる緩和された事後条件の例です。

Invariant-すべてのサブタイプで変更されないSelfDrivingVehicleのテンプレート。つまり、オーバーライドされた動作を実行して宛先に到達する順序。

ここでもう1つの方法を想定してみましょう

           -List<SelfDrivingVehicle> vehicles 
           +Add(SelfDrivingVehicle vehicle)
            vehicles.add(vehicle)

前提条件-ベースタイプのSelfDriveVehicleにはビークルがありません（ここではコンテキストはAddです）。プロパティのビークルを変更して明示的に強化することによってサブタイプのいずれかによって変更できないWeakened Precondition サブタイプはいずれも、Addを呼び出すだけです。

事後条件-追加が呼び出されると、ベースタイプは強化された事後条件になり、車両の値を変更することでサブタイプによって弱めることはできません。

基本動作の状態は、追加動作が呼び出されると元の状態に戻ります。

この例はほとんど打ちのめされていますが、正方形/長方形または円/楕円の可能性を考慮してください。長さと幅を持つオブジェクトを定義する基本クラスRectangleがあるとします。Rectangleクラスを継承するSquareクラスがある場合、長さまたは幅を変更すると対応するものが変更されることを要求するセッター/ゲッターにルールがあります。これらの寸法要件は、正方形の代わりに長方形がこれらの寸法要件を欠くため、前提条件を強化します。RectangleがSquareを継承するように継承を逆にすると、Rectangleが独立して動作できるように次元の要件を緩和することで事後条件を弱めることになります。

ただし、次元変更機能を削除する場合、長方形も正方形も次元を変更できない場合、継承に関係なく前と後の条件が等しくなるため、置換原則が適用されます。両方に長さがあり、両方に幅があり、どちらもこれらの値を変更できません。

ref：ウィキペディア-http://en.wikipedia.org/wiki/Liskov_substitution_principle