1 - 순수 자바코드로 개발(DIP,OCP,SRP)

💡 객체 지향 원칙

 

DIP,OCP,SRP 위반 -> 관심사 분리

DIP = 추상화된 것에만 의존 / OCP = 클라이언트 코드의 불변 / SRP = 단일 책임 원칙

이번 예제는 DIP 충족을 위한 코드변경 예시이며,
AppConfig는 코드의 중복이 존재하고 역할에 따른 '구현'이 불안정

DIP충족을 위한 예시로 대충 이해 용도로만 보자

• 기존의 코드는 클라이언트(구현 클래스)가 인터페이스,구현체에 의존함
• 클라이언트(구현 클래스)는 순수하게 인터페이스에만 의존하고 구체적인 구현체를 몰라야함
• AppConfig 파일을 생성해서 구체적인 구현 객체 생성을 AppConfig에서 담당 (관심사 분리)
• AppConfig 파일을 통해 구체적인 구현체의 의존성을 외부에서 주입받는것으로 (Dependendy Injection)
  DIP 를 충족한 코드가 되며 유지보수성이 좋아지고, 요구사항의 변경에 유연한 설계 가능

이해가 잘 안되서 메모장으로 써보면 이해가 잘됨

실행 App에서도 AppConfig를 통해 Service의 구현객체들을 불러오도록 코드 변경

MemberServiceTest 테스트코드 변경

OrderServiceTest 테스트코드 변경

모든 테스트 성공

---

💡 AppConfig 리팩터링

역할과 구현클래스를 나눔으로써 어플리케이션 전체구성의 가독성이 좋아지고 중복이 제거됨
코드 변경시 다른 코드들에 영향이 없음

 

현재 AppConfig에 코드의 중복이 존재함

FixDiscountPolicy(할인정책)도 명확한 '구현' 없이 선언 되어있음

코드를 이렇게 변경하면 메소드명을 보고 역할을 한 눈에 알수 있고, 코드의 중복이 사라짐 / 만약 나중에 DB를 교체한다고 하면 MemoryMemberRepository를 변경한 DB로만 변경해주면 된다

 

만약 할인정책을 변경하고 싶으면 변경에 영향을 받을 파일은 AppConfig밖에 없다

 

변경 전

변경 후

테스트도 고정할인 -> %할인으로 변경이 잘 적용된 모습

---

DI Container

• AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해줌