前提条件の強化と事後条件の弱化はどのようにリスコフ置換の原則に違反しますか？

Question

私はLiskovの代入原理が次の場合に違反することを読みました：

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

2. 事後条件が緩和されます

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

Answer 1

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

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

これらはもちろんささいな例ですが、コンセプトはそのままです。ファイル/データベース接続を開いたままにするようなものは、問題を引き起こす緩和された事後条件の例です。

Answer 2

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

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

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

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

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

Add Behaviorが呼び出されると、基本タイプの状態は元の状態に戻ります。