オブジェクト向け設計原則SOLID

開始します.
コンピュータのプログラミングを行うときに従うべきオブジェクト向けの設計の5つの原則と、SOLIDの理解を記録します.
定義＃テイギ＃
SOLIDはロバート・マーティンが2000年代初期に「クリーンコード」で知られた原則で、各文字は一つの原則を指していた.
詳細
SRP:単一責任原則
OCP:オープン/クローズの原則
LSP:リスコフ交換の原則
ISP:インターフェース分離の原則
DIP:逆転依存の原則
それぞれの原則をもっと詳しく知りましょう.
SRP (Single Responsibility Principle)
鉛筆の先で書くことができますが、拭き取れません.

まず,SOLIDにおけるSのSRP単一責任の原則である.
オブジェクト向けプログラミングでは、クラスは1つの責任しか負いません.そして、その階級は完全に責任をカプセル化しなければならない.
ここで、一つの責任は何を意味しますか?
オブジェクト向けプログラミングでは,責任の基準は変更である.一部のクラスまたはモジュールには、変更する理由が1つしかない必要があります.
たとえば、レポートの編集と出力では、2つの理由で変更される場合があります.1つはレポート内容の変更、2つはレポートフォーマットの変更です.この2つの理由は、レポートを変更するためにSRPに違反する可能性があります.SRPの要求を満たすために、私たちはこの2つの責任を明確に分けなければならない.
OCP (Open/Closed Principle)
クリップのデザインを不要に変更することなく、クリップ内の3つのカードに拡張できます.

第二に,SOLIDにおけるOに対応する開放‐閉鎖の原則を示した.
ソフトウェアオブジェクト(クラス、モジュール、関数など)は展開のために開く必要があり、変更は閉じた状態にする必要があります.ソフトウェア開発で使用する複数のモジュールのうち1つを変更する必要がある場合は、そのモジュールに関連する他のすべてのモジュールを1つずつ変更する必要があります.これは困難なタスクです.
各モジュールがオープンクローズの原則に合致する場合は、機能を追加または変更する必要があるときに正しく実行された元のコードを変更することなく、機能を追加または変更できます.
ただし、変更に対してクローズした場合、拡張は開くことができますか?そう思うこれは、既存のコードを変更して拡張するのは当然だからです.この場合、オブジェクト向けフィーチャーの1つであるマルチフォーム化が使用されます.新しいクラスを作成してインタフェースを実装し、新しい機能を実現できます.
Javaコードとして実装:

public class MemberService{
	private MemberRepository memberRepository = new MemoryMemberRepository();
}

上記のコードには、MemberRepositoryインタフェースを使用して実装されるMemoryMemberRepositoryクラスがあります.ただし、プログラムの実行中に、MemoryMemberRepositoryの代わりに他のクラスを使用する必要がある場合があります.
この場合、MemberRepositoryを実装するクラスをもう1つ作成し、必要な機能を適用し、MemberServiceクラスでMemberRepositoryとして再宣言するだけでよい.

public class MemberService{
//	private MemberRepository memberRepository = new MemoryMemberRepository();
	private MemberRepository memberRepository = new JdbcMemberRepository();
}

これにより、メンバーサービスというクラスは、コードを変更せずに既存のメンバーRepositoryを使用することができる.
これにより、MemoryMemberRepositoryからJdbcMemberRepositoryへの変更は、使用中のMemberServiceクラスのコードを変更することなく機能拡張を実現できます.
ただし、この代替メンバー・レポートは、「メンバー・サービス」という名前のクライアント・コードに既存のコードを注釈し、新しいコードの行を挿入する必要があります.これは、OCPの原則が守られていないことを意味します.
では、これらの問題をどのように解決しますか?
この問題を解決するには、オブジェクトを作成し、関連付けられた関係を作成する個別のコンポーネント(つまり、MemberRepositoryとMemberServiceの間に新しいクラスを配置する)で2つのクラス間の関係を管理する必要があります.スプリングはbeanの作成と注入によってこの問題を簡略化する.
LSP (Liskov Substitution Principle)
私たちはアクセルを踏んで前へ行きます.

3つ目はSOLIDのLに相当するリスク両替の原則です
1987年、バーバラ・リスコフが「データ抽象と階層」をテーマにしたテーマ演説で、リスコフ交換の原則は初めて紹介された.
コンピュータプログラムのデータ型Sがデータ型Tのサブタイプである場合、必要なプログラム属性(正確性、操作など)を変更することなく、データ型Tのオブジェクトをデータ型Sのオブジェクトに置き換える(置き換える)ことができる必要がある.
簡単に言えば、アプリケーションの精度を損なうことなく、アプリケーション内のオブジェクトをサブタイプのインスタンスに変換できる必要があります.
多形性では、サブクラスはインタフェースのすべての約束を守らなければなりません.この原則は、インタフェースを実装した実施体を信頼し、使用するために必要である.
実際の生活の例として、自動車インタフェースのアクセルは前に進まなければならない.車のアクセルというものに対する人々の合意は当然だからだ.
インタフェースを人々の間のアクセルに対する承諾と見なし,インタフェースの実現レベルを実際に生成された自動車のアクセルと見なせば容易に理解できる.
ISP (Interface Segregation Principle)
自動車は昇降機能を必要としない.自動車修理工場が必要です.

第四に,SOLIDのIに対応するインタフェース分離の原則である.
クライアントは、使用しない方法に依存してはいけません.
複数の特定のクライアントインタフェースは、1つの汎用インタフェースよりも優れています.
自動車の例として、自動車インタフェースは、運転インタフェースとメンテナンスインタフェースとに分離することができる.
例えば、ユーザクライアントは、運転者クライアントと整備者クライアントに分割することができる.このように分離すれば、メンテナンスインタフェースが変化しても運転手のクライアントに影響しません.要するに、インタフェースはより明確で、より代替的である.
DIP (Dependency Inversion Principle)
タクシーは必ずしもソナタではない.

最後にSOLIDに対応するDの依存関係逆転の原則
依存関係の逆転の原則は、次の2つの原則に従います.
第一に、上位モジュールは下位モジュールに依存できない.親モジュールと子モジュールは抽象に依存します.
第二に、抽象化は細部に依存してはならない.細部は抽象に頼らなければならない.
簡単に言えば、これは実装クラスに依存せず、インタフェースに依存することを意味する.
役割.タクシーを呼んだのですが、ソナタなら乗らないことはありません.学校に遅刻する危険がある場合は、タクシーというキャラクターに頼って、車種という具体的な事項を追及する時間がありません.
n/a.結論
オブジェクト向けプログラミングの5つの重要な原則を理解した.オブジェクト向けのコアである多形性を活用し、これらの原則を遵守し、良好なプログラミングを行うことが重要です.
参考文献
スプリングコア原理講座
https://inf.run/sZLP
ウィキペディア
https://ko.wikipedia.org/wiki/SOLID_(オブジェクト向け設計) )