(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 つ以上のクラスが共通のデータを共有する (ただし、共通の動作はしない) 場合、共通のデータを 1 つのクラスに配置し、このデータを共有する各クラスにこのクラスを含める必要があります。
(45) 2 つ以上のクラスが共通のデータと動作 (つまり、メソッド) を持つ場合、これらの各クラスは、これらのデータとメソッドを表す共通の基本クラスを継承する必要があります。
(46) 2 つ以上のクラスが共通のインターフェイス (メソッドではなくメッセージを参照) を共有する場合、多態的に使用する必要がある場合にのみ、共通の基本クラスから継承する必要があります。
(47) オブジェクトタイプの表示のケースバイケース分析は一般的に間違っています。このような場合、ほとんどの場合、設計者はポリモーフィズムを使用する必要があります。
(48) 属性値表示のケースバイケース分析は間違っていることが多い。クラスは継承階層に分離され、各属性値が派生クラスに変換される必要があります。
(49) 継承関係を通じてクラスの動的セマンティクスをモデル化しないでください。静的セマンティクス関係を使用して動的セマンティクスをモデル化しようとすると、実行時に型が切り替わります。
(50)クラスオブジェクトを派生クラスに変えないでください。インスタンスが 1 つしかない派生クラスには注意してください。
(51) 実行時に新しいクラスを作成する必要があると考えられる場合は、一歩下がって、オブジェクトを作成していることを認識してください。次に、これらのオブジェクトをクラスに一般化します。
(52) 派生クラスで空のメソッド (つまり、何も行わないメソッド) を使用して基本クラスのメソッドをオーバーライドすることは違法であるべきです。
(53) オプションの組み込みと継承の必要性を混同しないでください。オプションの包含を継承としてモデル化すると、クラスの急増につながります。
(54) 継承階層を作成するときは、再利用可能なコンポーネントではなく、再利用可能なフレームワークを作成するようにしてください。
(55) 設計で多重継承を使用する場合は、間違いがあったと想定してください。間違いを犯していない場合は、それを証明する必要があります。
(56) オブジェクト指向設計で継承が使用されるときは常に、次の 2 つの質問を自問してください: (1) 派生クラスは、それが継承するものの特別な型ですか? (2) 基本クラスは派生クラスの一部ですか?
(57) オブジェクト指向設計で多重継承が見つかった場合は、基本クラスが実際に別の基本クラスの派生クラスになっていないことを確認してください。
(58) オブジェクト指向設計において、包含と関連付けのどちらかを選択する必要がある場合は、包含を選択してください。
(59) クラスのオブジェクトの簿記にグローバル データやグローバル関数を使用しないでください。クラス変数またはクラスメソッドを使用する必要があります。
(60) オブジェクト指向の設計者は、物理的な設計原則が論理的な設計を損なうことを許すべきではありません。ただし、論理設計に関する決定を行う際には、物理設計基準を使用することがよくあります。
(61) オブジェクトの状態を変更するためにパブリック インターフェイスをバイパスしないでください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
