序文：
日常的な開発プロジェクトの場合、それが開発の最初のフェーズにすぎず、その後の責任がなければ、自分で開発してパスすることができます (誰も頼まなければ)。
ただし、継続的に第 1 フェーズの開発を継続したり、後期の開発を維持したり、大規模なチームで開発したりするには、基本的に開発オブジェクトの原則を理解する必要があります。再利用性 性的発達の場合、いくつかの原則を知ることで、より効果的なコードが作成されます。
これらの原則は実践を通じて得られ、理解した後は、定期的な開発アイデアと設計コードのロジックが得られます。
1: 単一責任の原則
クラスは、機能モジュール内の対応するコード開発のみを担当します。
たとえば、従来のインターフェイス開発: 制御層コントローラーとサービス インターフェイス層の開発、DB データベース インタラクションおよびその他のモジュール。各クラスには独自の責任モジュールがあり、
コード開発をマージしないでください。その後のメンテナンス、コードの参照、およびレビュー機能に役立ちません。
2つ目: クラス内に関数が多すぎると、それらの関数を結合することと同じになり、いずれかの関数が変更されるとモジュール開発に影響を与える可能性があるため、これらの関数を分離する必要があります。
例: サービス インターフェイス層と DB データベース インタラクションが最初のフェーズに配置されている場合、データベース インタラクションの技術フレームワークを変更したい場合、多くのコード、変更、検査を考慮する必要がありますか?
2: 開閉の原理
ソフトウェア エンティティは、拡張に対してオープンにし、変更に対してクローズする必要があります。
つまり、ソフトウェア エンティティは、元のコードを変更せずに拡張するように努めるべきです。
このように考えると、後のメンテナンスや開発に便利です。新しい要件が変更された場合、元のコードは変更しないようにしてください。
2. 開発のための新しいインターフェース方法
3. 全体的なフレームワークが最適化されます。たとえば、以前のプロジェクトでは、すべてのインターフェイス ロジックの主題が 1 つのクラスに含まれていました。
このクラスには、主にビジネス ルール検証、パラメータ検査、データベース インタラクション、
インターフェイスまたはトランザクションごとに、実装層をカスタマイズし、基本クラスを継承し、3 つの API を実装し、後で新しいインターフェイスを開発します。インターフェイス クラスを追加して 3 つの API を実装するだけです。
3: リスコフ置換原理
基本クラス オブジェクトを参照するすべての場所は、そのサブクラス
オブジェクトを透過的に使用できます。ソフトウェア内で基本クラス オブジェクトがそのサブクラス オブジェクトに置き換えられた場合、プログラムはエラーや例外を生成しません。また、ソフトウェアがエンティティはサブクラス オブジェクトを使用するため、基本クラス オブジェクトを使用できない場合があります。
リスコフ置換原理は、開閉原理を実現するための重要な方法の 1 つです。サブクラス オブジェクトは基底クラス オブジェクトが使用されている場所で使用できるため、オブジェクトの定義には可能な限り基底クラス型を使用する必要があります。プログラムを作成し、実行時にオブジェクトを再度定義できます。そのサブクラス タイプを決定し、親クラス オブジェクトをサブクラス オブジェクトに置き換えます。
簡単に理解すると次のようになります。
継承を使用する場合、親クラスA、子クラスB、
親クラス A の場所を参照する場合、すべてのコードを B に置き換えることができます。これは、親クラスのメソッドをサブクラスに対して書き直さないようにするためです。そうしないと、人によって意見が異なるため、書き換えには役立ちません。多すぎる 後のメンテナンス、拡張、交換。
4: 依存関係逆転の原則
抽象化は詳細に依存すべきではなく、詳細は抽象化に依存する必要があります。
開発用インターフェイスを使用した、シンプルなビジネス実装層アプローチ。
依存関係逆転の原理により、プログラム コードまたは関連付け関係でパラメーターを渡すとき、つまり、変数型宣言、パラメーター型宣言、メソッドの戻り値にインターフェイスと抽象クラスを使用するときに、できるだけ高レベルの抽象層クラスを参照する必要があります。型宣言やデータ型変換などを行うために具象クラスを使用する代わりに、
抽象化層を導入すると、システムの柔軟性が良くなりますので、プログラム中では抽象化層を利用してプログラミングを行い、具象クラスは設定ファイルに記述するようにすると、システムの動作が変わっても抽象化層だけを必要とするようになります。元のシステムのソースコードを変更せずに構成ファイルを拡張および変更し、変更せずにシステムの機能を拡張し、オープンクローズ原則の要件を満たします。
5: インターフェース分離原則
単一の汎用インターフェイスの代わりに複数の専用インターフェイスを使用します。
つまり、クライアントは必要のないインターフェイスに依存すべきではなく、各インターフェイスは比較的独立した役割を引き受け、すべきでないことは行わないようにします。
これも単一責任の利点と同様で、インターフェースクラスを設計する際には混同せず、分割用の機能モジュールなどを利用して差別化してください。
インターフェイスが引き受ける責任が多すぎると、インターフェイスの実装クラスが非常に大きくなり、インターフェイスで定義されたすべてのメソッドを別の実装クラスに実装する必要が生じ、柔軟性が低下します。空のメソッドが大量にあると、システム内で無駄なコードが大量に生成され、コードの品質に影響を及ぼしますが、その一方で、クライアントは大規模なインターフェイス用にプログラミングしているため、プログラムのカプセル化によって問題が発生します。特定のプログラムで破棄されると、クライアントには表示されるべきではないメソッドが表示され、クライアント インターフェイスのカスタマイズは行われません。
6: 合成と再利用の原則
再利用の目的を達成するために、オブジェクトの継承ではなく合成を使用するようにし、
再利用する場合は、可能な限り合成/集約関係 (関連関係) を使用し、継承を少なくしてください。
継承による再利用の主な問題は、継承の再利用によってシステムのカプセル化が破壊されることです。継承によって基本クラスの実装の詳細がサブクラスに公開され、基本クラスの内部詳細が通常はサブクラスに表示されるためです。再利用は「ホワイト ボックス」再利用とも呼ばれます。基本クラスが変更されると、サブクラスの実装も変更する必要があります。基本クラスから継承された実装は静的であり、実行時に変更できません。十分な柔軟性がありません。継承は、限られた環境 (継承しないと宣言されていないクラスなど) でのみ使用できます。
例えば：
パブリッククラスBase{
...APIを待ってください
}
パブリッククラスBaseA{
//ベースオブジェクトを参照して上位メソッドを使用する
プライベートベースベース。
... など、baseA 固有の API;
}
7: デメテルの法則
ソフトウェア エンティティは他のエンティティとの対話をできるだけ少なくする必要があります。
モジュールの 1 つが変更されても、他のモジュールへの影響は最小限に抑えられ、拡張は比較的容易になります。これがソフトウェア エンティティ間の通信の制限です。Dimi Special法律では、ソフトウェア エンティティ間の通信の幅と深さを制限することが求められています。ディミットの法則により、システムの結合度を下げ、クラス間の疎結合関係を維持できます。
パブリック クラスを抽出します。各ビジネス モジュールはパブリック クラス モジュールと対話します。このパブリック クラス モジュールには、単一の関数を完了するためだけにビジネス レベルのコードをあまり多く含めることはできません。
重要なポイントについては、業務モジュールに直接アクセスせず、相互にAPIを呼び出し、その後の拡張を容易にする