オブジェクト向け設計5原則-OLID

9月28日にTILでまとめられたエンティティ5の原則

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

SRP単一責任原則

クラスは1つの責任しか負いません.

の責任は大きいかもしれないし、小さいかもしれない.

の文脈と状況とは異なります.

変更時の波及効果が小さい場合は、単一責任の原則に従います!

Ex) UI변경, 객체의 생성과 사용을 분리

OCP開放-閉鎖の原則

ソフトウェア要素は拡張時に開いていますが、変更時には閉じている必要があります.

新しいクラスを作成し、

インタフェースを実装して、新しい機能を実現します.
欠点

インプリメンテーションオブジェクトを変更するには、クライアントコードを変更する必要があります.(多形性を使用していますが、OCPの原則は守れません)
→オブジェクトを作成し、関連関係を個別に組み立てるには、設定者が必要です→これはスプリングによって助けられます!

LSPリスク両替の原則

プログラム内のオブジェクトは、プログラムの正確性を損なわずにサブタイプのインスタンスに変換できる必要があります.

多形性では、サブクラスはすべてのインタフェースの約束を守らなければならない.LSPはこの点を保証しなければならない.

すなわち、インタフェースを実現したインプリメンテーションを信頼して使用するためには、インプリメンテーションは、インタフェースを設計する際に所望の機能を正確に実現しなければならない.

Ex) 자동차 인터페이스에 엑셀 - 앞으로가는 기능이 있다고 했을 때,
구현체에 엑셀 - 뒤로가는 기능으로 구현하면 LSP 원칙을 위반한 것이다.

ISPインタフェース分離の原則

複数の特定のクライアントインタフェースは、1つの汎用インタフェースよりも優れています.(コードが短いのは良いことではありません!)

界面が明瞭になり,代替性も向上した.

Ex) 인터페이스 AB가 A와 관련된 업무 aa와 B와 관련된 bb업무를 한다고 했을 때,

인터페이스 AB를 인터페이스 A와 인터페이스 B로 분리하고 각각 aa와 bb의 역할을 하도록 업무 또한 분리!

DIP依存関係逆転の原則

それは

抽象化に依存し、具体化ではない.
→クライアントは実装クラスに依存せず、インタフェースに依存する.

ロールに依存する必要があります.

クライアントは、柔軟な変更を行うためにインタフェースに依存する必要があります.

オブジェクト向けのコアは多形性であるが,多形性だけではSOLIDを守れない.スプリングはDIとDI容器であり、多形性とSOLID(特にOCP、DIP)をサポートする.
つまり、新しいインプリメンテーションボディを作成するときに、クライアントコードを変更せずに機能を追加することで、部品を交換するように簡単に開発できます.