ホームページ >バックエンド開発 >PHPチュートリアル >PHP オブジェクト指向ルール_PHP チュートリアル
PHP オブジェクト指向ルール_PHP チュートリアル
- WBOYオリジナル
- 2016-07-21 15:20:35969ブラウズ
これらの原則に厳密に従う必要はなく、違反した場合の宗教上の罰則もありません。しかし、これらの原則は、いずれかが違反された場合に警鐘が鳴ると考えるべきです。 ----- 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 つを超えるデータ メンバーが含まれる場合、論理的に関連するデータ メンバーをグループに分割し、新しい包含クラスを使用してこのメンバーのグループを含めることができます。
(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) オブジェクトの状態を変更するためにパブリックインターフェースをバイパスしないでください。