PHP のオブジェクト指向設計について知っておくべきこと_PHP チュートリアル

これらの原則に厳密に従う必要はなく、違反した場合に宗教上の罰則はありません。しかし、これらの原則は、いずれかが違反された場合に警鐘が鳴ると考えるべきです。 -----アーサー・J・リエル

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. オブジェクトの状態を変更するためにパブリックインターフェイスをバイパスしないでください。

http://www.bkjia.com/PHPjc/752490.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/752490.html技術記事これらの原則に厳密に従う必要はなく、違反した場合の宗教上の罰則もありません。しかし、これらの原則は、いずれかが違反された場合に警鐘が鳴ると考えるべきです。 ...