객체지향 원리의 적용 ( DIP/OCP위반 문제점 해결하기)

1. 새로운 할인 정책 추가, 문제점 발생 

 

- 다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것 자체는 아무 문제가 없다.

• 새로운 할인 정책 적용과 문제점
  • 새로 개발한 정률 할인 정책을 적용하려고 하니 클라이언트 코드인 주문 서비스 구현체(OrderServiceImpl) 도 함께 변경해야한다. -> OCP위반 : 지금 코드는 기능을 변경하면, 클라이언트 코드를 변경해야 한다. 
  • 주문 서비스 클라이언트가 인터페이스인 DiscountPolicy 뿐만 아니라, 구체 클래스인 FixDiscountPolicy 도 함께 의존
  • ->  DIP 위반 ( DIP: 의존관계 역전 원칙  = 추상화에 의존하되, 구체화에 의존하지 말것) 

 

 

2. 관심사의 분리

 

1. AppConfig 에서 실제 동작에 필요한 구현객체를 생성하고,  

     ex. memberServiceImpl, MemoryMemberRepository, orderServiceImpl FixDiscountPolicy

2.생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.

   ex. MemberServiceImpl -> MemoryMemberRepository

          OrderServiceImpl -> MemoryMemberRepository, FixDiscountPolicy  

 

 

• MemberServiceImpl 는 단지 MemberRepository 인터페이스만 의존한다. MemoryMemberRepository 를 의존하지 않는다! 
• MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다. MemberServiceImpl 의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부( AppConfig )에서 결정된다.
  MemberServiceImpl 은 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 된다.

 

AppConfig 

• 애플리케이션을 하나의 공연으로 생각
• 기존에는 클라이언트가 의존하는 서버 구현 객체를 직접 생성하고, 실행함
• 비유를 하면 기존에는 남자 주인공 배우가 공연도 하고, 동시에 여자 주인공도 직접 초빙하는 다양한 책임을 가지고 있음. 공연을 구성하고, 담당 배우를 섭외하고, 지정하는 책임을 담당하는 별도의 공연 기획자가 나올 시점 -> 공연 기획자인 AppConfig가 등장
• AppConfig는 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임
• AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. 

 -> DI ( Dependency Injection) 의존관계 주입. 의존성 주입 이라고 한다. 생성자 주입이 일어난다. 

 

 

3. AppConfig 리팩토링

• 이제 변경하고 싶은 부분이 생기면 AppConfig만 변경하면 된다. 
• 구성 정보에서 역할과 구현을 명확하게 분리하였다.