PHP オブジェクト指向ルール

これらの原則に厳密に従う必要はなく、違反した場合の宗教上の罰則もありません。しかし、これらの原則は、いずれかが違反された場合に警鐘が鳴ると考えるべきです。 ----- 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 つ以上のクラスが共通のデータを共有する (ただし、共通の動作はしない) 場合、共通のデータを 1 つのクラスに配置し、このデータを共有する各クラスにこのクラスを含める必要があります。

(45) 2 つ以上のクラスが共通のデータと動作 (つまり、メソッド) を持つ場合、これらのクラスのそれぞれは、これらのデータとメソッドを表す共通の基本クラスから継承する必要があります。

(46) 2 つ以上のクラスが共通のインターフェース (メソッドではなくメッセージを参照) を共有する場合、多態的に継承する必要がある場合にのみ、共通の基本クラスから開始する必要があります。

(47) オブジェクトタイプの表示のケースバイケース分析は一般的に間違っています。このような場合、ほとんどの場合、設計者はポリモーフィズムを使用する必要があります。

(48) 属性値の表示のケースバイケース分析は間違っていることがよくあります。クラスは継承階層に分離され、各属性値が派生クラスに変換される必要があります。

(49) 継承関係を通じてクラスの動的セマンティクスをモデル化しないでください。静的セマンティクス関係を使用して動的セマンティクスをモデル化しようとすると、実行時に型が切り替わります。

(50) クラスオブジェクトを派生クラスにしないでください。インスタンスが 1 つしかない派生クラスには注意してください。

(51) 実行時に新しいクラスを作成する必要があると考えられる場合は、一歩下がって、オブジェクトを作成していることを認識してください。次に、これらのオブジェクトをクラスに一般化します。

(52) 派生クラスで空のメソッド (つまり、何も行わないメソッド) を使用して基本クラスのメソッドをオーバーライドすることは違法であるべきです。

(53) オプションの組み込みと継承の必要性を混同しないでください。オプションの包含を継承としてモデル化すると、クラスの急増につながります。

(54) 継承階層を作成するときは、再利用可能なコンポーネントではなく、再利用可能なフレームワークを作成するようにしてください。

(55) 設計で多重継承を使用する場合は、間違いがあったと想定してください。間違いを犯していない場合は、それを証明する必要があります。

(56) オブジェクト指向設計で継承が使用されている限り、次の 2 つの質問を自問してください: (1) 派生クラスは継承するものの特別な型ですか? (2) 基本クラスは派生クラスですか? ? クラスの一部ですか?

(57) オブジェクト指向設計で多重継承が見つかった場合は、基本クラスが実際に別の基本クラスの派生クラスになっていないことを確認してください。

(58) オブジェクト指向設計において、包含と関連性のどちらかを選択する必要がある場合は、包含を選択してください。

(59) クラスオブジェクトのブックキーピングにグローバルデータやグローバル関数を使用しないでください。クラス変数またはクラスメソッドを使用する必要があります。

(60) オブジェクト指向の設計者は、物理的な設計原則が論理的な設計を損なうことを許すべきではありません。ただし、論理設計に関する決定を行う際には、物理​​設計基準を使用することがよくあります。

(61) オブジェクトの状態を変更するためにパブリックインターフェースをバイパスしないでください。