リスコフの置換原則は、状態の不変量の保護に関係していますか？
Wiki さんのコメント：
置換可能性は、オブジェクト指向プログラミングの原則であり、コンピュータプログラムでは、SがTのサブタイプである場合、タイプTのオブジェクトをタイプSのオブジェクトに置き換えることができます（つまり、タイプTのオブジェクトをサブタイプSのオブジェクト）Tの望ましいプロパティ（正しさ、実行されたタスクなど）を変更しません。
これからの私の理解、
TがTのインスタンスによって維持される state の不変量を保護するためのカプセル化を提供する抽象化である場合、Sは抽象化ですその最低でもカプセル化を提供して、同じそれらの継承された状態の不変条件を保護するSのインスタンス。
ここで、抽象化はクラスであるだけでなく、関数でもあり得ます。例： function プロトタイプのパラダイムで記述（ES5 JavaScript）
クラス（TまたはS）は、インスタンスが従う必要のあるコントラクトを知っています。
LSPは約Sであり、Tから継承される状態の不変条件を保護するためのカプセル化を保証します。私の理解では、正しさは、状態の正しさを維持するために不変条件を保護することです。
それは正しい理解ですか？
いいえ、そうは思いません。
LSPによると、SはTの代わりに使用できます。実際には、SはTと同じ契約上の義務を果たします。Sの作成者は公開できます。元のAPIコントラクトに違反することなく、内部状態（それによってカプセル化を破る）。
状態は実装の詳細であり、動作ではありません。
完全ではありません。一部の基本クラスがその状態の不変性を保証する場合、そのサブタイプもその保証を提供する必要があります。一部の基本クラスがその状態に対して不変の関係を保証する場合、そのサブタイプもその保証を行う必要があります。ただし、クラス（および関数）の「望ましいプロパティ」には、それらの状態の動作よりもはるかに多くあります。
それを見る別の良い方法は、リスコフの元の論文に記載されています この質問 要約：サブタイプは前提条件を強化したり事後条件を弱めたりすべきではありません。