これらの原則に厳密に従う必要はなく、違反した場合の宗教上の罰則もありません。しかし、これらの原則は、いずれかが違反された場合に警鐘が鳴ると考えるべきです。 -----アーサー・J・リエル
(1) すべてのデータは、それが配置されているクラス内に隠蔽される必要があります。
(2) クラスのユーザーはクラスのパブリック インターフェイスに依存する必要がありますが、クラスはそのユーザーに依存することはできません。
(3) クラスプロトコル内のメッセージを最小限に抑えます。
(4) すべてのクラスが理解できる最も基本的なパブリック インターフェイス [たとえば、コピー操作 (深いコピーと浅いコピー)、等価性の判断、正しい出力内容、ASCII 記述からの解析など] を実装します。
(5) 実装の詳細 (共有コードを配置するプライベート関数など) をクラスのパブリック インターフェイスに含めないでください。
クラスの 2 つのメソッドに共通のコードがある場合、この共通のコードを防ぐプライベート関数を作成できます。
(6) ユーザーが使用できないものや興味のないものでクラスのパブリック インターフェイスを妨害しないでください。
(7) クラス間の結合がゼロであるか、エクスポートされた結合関係のみが存在する必要があります。つまり、あるクラスは別のクラスとまったく関係がないか、別のクラスのパブリック インターフェイスでの操作のみを使用するかのどちらかです。
(8) クラスは 1 つのキー抽象化のみを表す必要があります。
同じタイプのプロパティの変更に対して、パッケージ内のすべてのクラスを共同で閉じる必要があります。変更がパッケージに影響を与える場合、そのパッケージ内のすべてのクラスに影響しますが、他のパッケージには影響しません
。
(9) 関連するデータと行動を一元化します。
デザイナーは、get などの操作を通じて他のオブジェクトからデータを取得するオブジェクトに注意を払う必要があります。このタイプの動作は、この経験原則に違反していることを意味します。
(10) 関係のない情報を別のクラスに入れる(つまり、お互いにコミュニケーションをとらない行為)。
安定への依存
(11) モデル化する抽象概念が、オブジェクトによって果たされる役割だけでなく、クラスであることを確認してください。
(12) システム機能を水平方向にできるだけ均一に分散します。つまり、設計に従って、最上位クラスは作業を均一に共有する必要があります。
(13) システム内に全能のクラス/オブジェクトを作成しないでください。 Driver、Manager、System、および Susystem を名前に含むクラスには特に注意してください。
インターフェースを実装するのではなく、インターフェースを計画します。