これらの原則に厳密に従う必要はなく、違反した場合の宗教上の罰則もありません。しかし、これらの原則は、いずれかが違反された場合に警鐘が鳴ると考えるべきです。 ----- Arthur J.Riel
(1) すべてのデータは、それが配置されているクラス内で隠蔽される必要があります。
(2) クラスのユーザーはクラスの共有インターフェースに依存する必要がありますが、クラスはそのユーザーに依存することはできません。
(3) クラスプロトコル内のメッセージを最小限に抑えます。
(4) すべてのクラスが理解できる最も基本的なパブリック インターフェイス [たとえば、コピー操作 (深いコピーと浅いコピー)、等価性の判断、正しい出力内容、ASCII 記述からの解析など] を実装します。
(5) 実装の詳細 (共有コードを配置するプライベート関数など) をクラスのパブリック インターフェイスに含めないでください。
クラスの 2 つのメソッドに共通のコード部分がある場合、その共通コードを防止するプライベート関数を作成できます。
(6) ユーザーが使用できないものや興味のないものでクラスのパブリック インターフェイスを妨害しないでください。
(7) クラス間の結合はゼロであるか、派生結合関係のみが存在する必要があります。つまり、あるクラスは別のクラスとまったく関係がないか、別のクラスのパブリック インターフェイスでの操作のみを使用します。
(8) クラスは 1 つのキー抽象化のみを表す必要があります。
同じタイプのプロパティの変更に対しては、パッケージ内のすべてのクラスを共同で閉じる必要があります。変更がパッケージに影響を与える場合、そのパッケージ内のすべてのクラスに影響しますが、他のパッケージには影響しません。
(9) 関連するデータと動作を一元化します。
設計者は、get などの操作を通じて他のオブジェクトからデータを取得するオブジェクトを認識する必要があります。このタイプの動作は、この経験原則に違反していることを意味します。
(10) 関係のない情報は別のカテゴリーに入れる（つまり、コミュニケーションをとらないという行為）。
(11)オブジェクト
が果たす役割だけでなく、モデル化する抽象概念がクラスであることを確認します。
(12) システム機能を水平方向にできるだけ均一に分散します。つまり、設計に従って、最上位クラスは作業を均一に共有する必要があります。
(13) システム内に全能のクラス/オブジェクトを作成しないでください。 Driver、Manager、System、および Susystem を名前に含むクラスには特に注意してください。
インターフェイスを実装するのではなく、インターフェイスを計画します。
(14) パブリックインタフェースに多数のアクセスメソッドを定義するクラスには注意してください。アクセス方法が多数あるということは、関連するデータと動作が集中的に保存されていないことを意味します。
(15) 相互に通信しない動作が多すぎるクラスには注意してください。
この問題のもう 1 つの兆候は、アプリケーション内のクラスのパブリック インターフェイスに多数の get 関数と set 関数が作成されていることです。
(16) ユーザーインターフェースと対話するオブジェクト指向モデルで構成されるアプリケーションでは、モデルはインターフェースに依存すべきではありませんが、インターフェースはモデルに依存する必要があります。
(17) 可能な限り現実世界に従ってモデルを作成します (システム機能分散の原則を遵守し、汎用クラスの原則を回避し、関連するデータと動作を一元的に配置するために、この原則に違反することがよくあります)。
(18) デザインから不要なクラスを削除します。
通常、このクラスをプロパティにダウングレードします。
(19) システム外のクラスを削除します。
システム外部のクラスの特徴は、抽象的に言えば、システム ドメインにメッセージを送信するだけで、システム ドメイン内の他のクラスからのメッセージは受け付けないことです。
(20) オペレーションをクラスに変えないでください。名前が動詞であるか動詞から派生したクラス、特に意味のあるアクションが 1 つだけあるクラスには質問してください。その意味のある動作を、既存のクラスまたはまだ発見されていないクラスに移動する必要があるかどうかを検討してください。
(21) アプリケーションの分析モデルを作成するときに、プロキシ クラスを導入することがよくあります。設計段階では、多くのエージェントが役に立たず、削除する必要があることがわかります。
(22) クラスの協力者の数は最小限に抑えます。
クラスで使用される他のクラスの数は最小限に抑える必要があります。
(23) クラスとコラボレータ間で受け渡されるメッセージの数を最小限に抑えます。
(24) クラスとコラボレーター間のコラボレーションの量を最小限に抑えます。つまり、クラスとコラボレーターの間で受け渡されるさまざまなメッセージの数を減らします。
(25) クラスのファンアウトを最小限に抑えます。つまり、クラスによって定義されたメッセージの数と送信されるメッセージの数の積を減らします。
(26) クラスに別のクラスのオブジェクトが含まれている場合、それを含むクラスは、含まれているオブジェクトにメッセージを送信する必要があります。つまり、包含関係は常に使用関係を意味します。
(27) クラス内で定義されたほとんどのメソッドは、ほとんどの場合、ほとんどのデータ メンバーを使用する必要があります。
(28) クラスに含まれるオブジェクトの数は、開発者の短期記憶の容量を超えてはなりません。この数は多くの場合 6 です。
クラスに 6 つを超えるデータ メンバーが含まれる場合、論理的に関連するデータ メンバーを 1 つのグループに分割し、新しい包含クラスを使用してこのメンバーのグループを含めることができます。
(29) システム機能を狭く深い継承体系で垂直に分散させる。
(30) セマンティック制約を実装するときは、クラス定義に従って実装するのが最善です。これは多くの場合、クラスのオーバーフローにつながります。この場合、制約はクラスの動作に実装する必要があります。通常はコンストラクターに実装する必要がありますが、必ずしもそうである必要はありません。
(31) クラスのコンストラクターにセマンティック制約を実装する場合、コンストラクターのドメインで許可される最も深い包含レベルに制約テストを配置します。
(32) 制約が依存するセマンティック情報が頻繁に変更される場合は、それを集中管理されたサードパーティ オブジェクトに置くのが最善です。
(33) 制約が依存するセマンティック情報がめったに変更されない場合、制約に関係するクラス間で分散するのが最適です。
(34) クラスは、そのクラスに何が含まれているかを知る必要がありますが、誰がそれを含んでいるかを知ることはできません。
(35) リテラルスコープを共有する (つまり、同じクラスに含まれる) オブジェクトは、相互に使用関係を持つべきではありません。
(36)継承は、専門化階層をモデル化するためにのみ使用されるべきです。
(37) 派生クラスは基底クラスについて知っている必要がありますが、基底クラスは派生クラスについての情報を知っていてはなりません。
(38) 基本クラス内のすべてのデータはプライベートである必要があり、保護されたデータを使用しないでください。
クラスの設計者は、クラスのユーザーが必要としないものをパブリック インターフェイスに決して配置すべきではありません。
(39) 理論的には、継承階層は深くあるべきであり、深ければ深いほど良いです。
(40) 実際には、継承階層の深さは平均的な人の短期記憶容量を超えてはなりません。広く受け入れられている深さの値は 6 です。
(41) すべての抽象クラスは基本クラスである必要があります。
(42) すべての基底クラスは抽象クラスである必要があります。
(43) データ、動作、および/またはインターフェイスの共通性を継承階層の可能な限り上位に配置します。
(44) 2 つ以上のクラスが共通データを共有する (ただし、共通の動作はしない) 場合、共通データは、このデータを共有する各クラスに含まれるクラスに配置される必要があります。
(45) 2 つ以上のクラスが共通のデータと動作 (つまり、メソッド) を持つ場合、これらの各クラスは、これらのデータとメソッドを表す共通の基本クラスから継承する必要があります。
(46) 2 つ以上のクラスが共通のインターフェイス (メソッドではなくメッセージを参照) を共有する場合、多態的に使用する必要がある場合にのみ、共通の基本クラスから継承する必要があります。
(47) オブジェクトタイプの表示に関するケースバイケースの分析は、一般的に間違っています。このような場合、ほとんどの場合、設計者はポリモーフィズムを使用する必要があります。
(48) 属性値の表示のケースバイケース分析は間違っていることがよくあります。クラスは継承階層に分離し、各属性値を派生クラスに変換する必要があります。
(49) 継承関係を通じてクラスの動的セマンティクスをモデル化しないでください。静的セマンティクス関係を使用して動的セマンティクスをモデル化しようとすると、実行時にタイプが切り替わります。
(50) クラスオブジェクトを派生クラスにしないでください。インスタンスが 1 つしかない派生クラスには注意してください。
(51) 実行時に新しいクラスを作成する必要があると思われる場合は、一歩下がって、オブジェクトを作成していることを認識してください。次に、これらのオブジェクトをクラスに一般化します。
(52) 派生クラスで空のメソッド (つまり、何も行わないメソッド) を使用して、基本クラスのメソッドをオーバーライドすることは違法であるべきです。
(53) オプションの組み込みと継承の必要性を混同しないでください。オプションの包含を継承としてモデル化すると、クラスの急増につながります。
(54) 継承階層を作成するときは、再利用可能なコンポーネントではなく、再利用可能なフレームワークを作成するようにしてください。
(55) 設計で多重継承を使用する場合は、間違いがあったと想定してください。間違いを犯していない場合は、それを証明する必要があります。
(56) オブジェクト指向設計で継承が使用されるときは常に、次の 2 つの質問を自分自身に問いかけてください: (1) 派生クラスは、それが継承するものの特別な型ですか? (2) 基本クラスは派生クラスの一部ですか?
(57) オブジェクト指向設計で多重継承が見つかった場合は、基本クラスが実際に別の基本クラスの派生クラスになっていないことを確認してください。
(58) オブジェクト指向設計において、包含と関連性のどちらかを選択する必要がある場合は、包含を選択してください。
(59) クラスのオブジェクトの簿記にグローバル データやグローバル関数を使用しないでください。クラス変数またはクラスメソッドを使用する必要があります。
(60) オブジェクト指向の設計者は、物理的な設計原則が論理的な設計を損なうことを許すべきではありません。ただし、論理設計に関する決定を行う際には、物理設計基準を使用することがよくあります。
(61) オブジェクトの状態を変更するためにパブリック インターフェイスをバイパスしないでください。