[TIL] 21.08.03
こしょう
Feelings(感覚・主観)
今回は普段から興味のある対象者向けの講座を聞きました.
授業を受けて感じたのは、自分が当たり前だと思っている「カプセル化」、「継承」、「抽象化」、「多形性」などの概念だけを大まかに理解していたことです.
後で宣伝を行い、概念を他の人に説明できる程度に固めなければならない.
commit、merge、push、pullのブログだけ見て勉強したので、襟の動きのメカニズムがよく理解できませんでした.
陳幼林さんの簡単な説明と実習のプレゼンテーションのおかげで、襟の動作過程を体験しました.
私はまだあなたが後半に提出した深化概念を完全に理解していませんが.
Infranの陳儒林の講義で内容を整理し直す
Findings(ラーニングポイント)
基本的なネクタイの使い方と新しい概念を復習します
- rebase
UML図の使い方を学びました.
オブジェクト向けプロパティ(カプセル化、継承、抽象化、多形性)
オブジェクト向け設計の5つの原則
良好なオブジェクト向け設計五原則(SOLID)
SRP:単一責任原則
1階級には1つの責任しかない.
OCP:オープン/クローズの原則
拡張はオープンですが、境界は閉鎖されなければなりません.
つまり、拡張機能ではソースコードの変更は発生しません...
実装インタフェースの新しいクラスを作成して、新しい機能を実現します.
(多形性利用)
に質問
MemberRepositoryインタフェースを定義し、機能を拡張する場合は...
public class MemberService {
// private MemberRepository memberRepository = new MemoryMemberRepository();
private MemberRepository memberRepository = new JdbcMemberRepository();
}複数のプロファイルを使用している場合でも、クライアントのソースは上記のように変更されます.
→OCP原則が破られる
→オブジェクトを作成し、関連付けを確立するには、個別の設定器が必要です!(スプリングのキャラクター)
LSP:リスコフ置換原則(Liskov置換原則)
多形性では、サブクラスはすべてのインタフェースの約束を守らなければなりません.
ISP:インターフェース分離の原則
複数の特定のクライアントインタフェースは、1つの汎用インタフェースよりも優れています.
インタフェースを特定の責任に分ける.
-より明確なインターフェースと代替性
-保守が容易
Ex)
自動車インタフェース→運転インタフェース、メンテナンスインタフェース分離
ユーザクライアント→運転者クライアント、整備員クライアント分離
自動車のメンテナンスインターフェースを変更しても運転手のクライアントに影響しません
→変更点の最小化(SRP)
DIP:依存関係逆転の原則
클라이언트 코드가 구현체에 의존하지 말고 인터페이스에 의존해야 한다.
**(역할에 의존해야 한다.)**
- 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다.
- MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존하고 있는 것임 → **DIP 위반** public class MemberService {
// 구현 클래스를 직접 선택하고 있다.
private MemberRepository memberRepository = new MemoryMemberRepository();
}次の平面(計画)
確認(自己宣言)
1.TILを毎日作成する
2.「時間がかかっても勉強が多くない」
3.勉強の内容は必ず整理してからひっくり返す
Reference
この問題について([TIL] 21.08.03), 我々は、より多くの情報をここで見つけました https://velog.io/@devrunner21/21.08.03テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol