スプリングベースsec 3.オブジェクト指向原理の適用

section 2で記述された純粋なjavaコードの多くの問題が発見された.再包装の時.
SOLIDの5つの原則をどのように守るかを重点的に学ぶ.내용 및 다이어그램 및 코드 부분 인용의 모든 출처는 김영한님의 인프런 스프링 강의입니다.

新しい割引ポリシーと問題の適用

固定割引->レート割引に変更するなら?

public class OrderServiceImpl implements OrderService {
	// private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
 	private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}

新しく開発された価格設定割引ポリシーを適用するには、クライアント・コード-オーダー・サービス・インプリメンテーション->OCP違反を同時に変更する必要があります.
オーダーサービスクライアントはDiscountPolicyインタフェースです.
FixDiscountPolicyも依存->DIP違反

交換しよう

1.インタフェースのみに依存するように変更

public class OrderServiceImpl implements OrderService {
 	//private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
 	private final DiscountPolicy discountPolicy;
}

そうするとfinalは必ず初期化しなければならないので直接運転すると恐ろしいNPEが発生します
そのため、DiscountPolicyの実施対象を
生成して注入する必要があります.
2.AppConfig登場
アプリケーションの完全な動作(config)を構成するには、実装オブジェクトの作成と接続を担当する個別の設定クラスを作成する必要があります.

public class AppConfig {
   public MemberService memberService() {
   	return new MemberServiceImpl(new MemoryMemberRepository());
 }
   public OrderService orderService() {
     return new OrderServiceImpl(
       new MemoryMemberRepository(),
       new FixDiscountPolicy());
   }
}
/*참고 - 리팩토링 전 코드다*/

/*클라이언트 코드에는 생성자를 추가한다.*/
public class MemberServiceImpl implements MemberService {
   private final MemberRepository memberRepository;
   public MemberServiceImpl(MemberRepository memberRepository) {
 	this.memberRepository = memberRepository;
   }
   기능기능기능
}

AppConfigアプリケーションの実際の操作に必要な実施対象を生成します.

AppConfig生成されたオブジェクトインスタンスの参照(参照)をコンストラクタを介して

に注入(接続)する.

MemberServiceImplは、実行に専念するだけで、依存関係の悩みを外部(AppConfig)に任せるようになりました.

3.AppConfig再包装
AppConfig.Javaのコードから重複するコードが見え、ロールベースの実装は見えません.

public class AppConfig {
 public MemberService memberService() {
 	return new MemberServiceImpl(memberRepository());
 }
 public OrderService orderService() {
 	return new OrderServiceImpl(
 	  memberRepository(),
 	  discountPolicy());
 }
 public MemberRepository memberRepository() {
 	return new MemoryMemberRepository();
 }
 public DiscountPolicy discountPolicy() {
 	return new FixDiscountPolicy();
 }
}

再包装後:

新しいMemoryMemberRepository()重複除外部分.
これで、MemoryMemberRepositoryを別のインプリメンテーションに変更する場合は、一部を変更するだけです.

AppConfigでは、ロールとインプリメンテーションクラスが一望できます.
アプリケーション全体の構成をすばやく理解します.

クラス図

appConfigオブジェクトMemoryMemberRepositoryオブジェクトを作成し、その参照値をジェネレータとしてMemberServiceImplに渡します.

クライアントメンバーサービスImplの観点から、依存関係は外部から注入されたように、依存注入(DI)韓国語ではどのように依存関係注入または依存性注入と呼ぶのか.

結果はね。

DIP:(インタフェース変数のみを宣言して終了するため、抽象のみに依存)
OCP:(AppConfigはもちろん変更しますが、クライアントコードは変更しません)
最終的に二人とも守ってくれました!!!

整理する

プロセス全体をまとめ、設計が良好なオブジェクト向けの5つの原則(まとめですが)
この部分はとても重要で、ブログを見るよりpdfと講義で復習したほうがいいです.ほほほ

IoC

OrderServiceImplヘルパーインタフェースを呼び出しますが、どのインプリメンテーションオブジェクトが実行されるか分かりません.
これらの制御権はAppConfigに転送されました.さらにOrderServiceImplでもAppConfigが作成されています.

フレームとライブラリ(突然?)

フレームワークは私が書いたコードを制御し、それを実行するのがフレームワークです.(JUnit)
逆に、私が作成したコードがストリームの制御を直接担当している場合は、フレームワークではなくライブラリです.
Junitの場合、JUnitを使用してテストを記述する場合、@Testでは開発者は論理のみを作成し、JUnitは実行と制御権を有します.
自分のライフサイクルに入る(@BeforeEach、@AfterEachコメントなど)