交換原則として（LSP：リスコフの置換原則）
機能は、ベースクラスへの参照の使用ポインタが、それを知らずに、派生クラスのオブジェクトを使用することができなければならないということ。（サブクラスオブジェクト（サブタイプ/派生クラスのオブジェクト）は、親オブジェクト（ベース/親クラスのどこにでもオブジェクト）のプログラム（プログラム）に置き換えることができる発生し、その元のプログラム（動作）の論理的挙動と同様の正確さを確保破壊されません。）
ビューの説明および定義コード実装の観点から、交換における多型は、幾分類似しているが、彼らの懸念の角度は同じではありません。
多型は、オブジェクト指向プログラミングの主要な機能であり、オブジェクト指向プログラミング言語の構文です。それは達成するためのトランスコーディングのアイデアです。
交換は、設計原理をここそして、交換用の親クラスは、元のプログラムのロジックを変更しないことを保証するために、サブクラスのデザインを設計する方法を継承中性子クラスを導くために使用され、元のプログラムを破壊しません正しさ。
実際には、別の原理は中国語の翻訳は、「設計によって契約」であるより有能な床、より記述指導によって置き換えであり、「プロトコルの設計に基づいて。」
デザイン、行動親でサブクラスは、契約（またはと呼ばれるプロトコル）に準拠します。親クラスは、行動の機能は、サブクラスが機能ロジックの内部実装を変更することができますが、契約の本来の機能の動作を変更することができないことで合意した定義します。
ここでの行動規則が含まれます：達成すべき機能の関数宣言を、入力、出力、異常な慣習;でもコメントに特別な指示が記載されています。
実際には、親と子のクラス間の関係の定義は、インタフェースと実装クラス間の関係に置き換えてもよいです。
要約
交換原則的には、中性子クラス設計の方法を継承の原則を導くために使用されています。どこ交換原理を理解し、コアは言葉を「設計することで合意によると、契約による設計」を理解することです。親クラスは、サブクラスは、機能ロジックの内部実装を変更することができることを、「契約」関数（またはプロトコルと呼ばれる）を定義するが、本来の機能変更できない「契約」を ここで慣例は：達成すべき機能の関数宣言、入力、出力、異常な規則を、偶数リストされた注釈として特別な命令を含みます。