Practice3. 객체지향 원리 적용

새로운 할인 정책 개발

---

• RateDiscountpolicy 추가

Issue

• 할인 정책을 변경하려면 클라이언트(0rderServiceImpl) 코드를 직접 수정해야 한다.
• 그렇게 되면 DIP/OCP를 위반하게 된다.

DIP

• 구현체 의존

 DiscountPolicy discount = new FixDiscountPolicy();

OCP 위반 

• 클라이언트 코드 변경

 //DiscountPolicy discount = new FixDiscountPolicy();
DiscountPolicy discount = new RateDiscountPolicy();

 

해결 방안

• 클라이언트에 DiscountPolicy의 구현 객체를 대신 생성하고 주입할 무언가가 필요하다.

 

 

관심사의 분리

---

AppConfig 생성

• 애플리케이션의 전체 동작 방식을 구성하기 위해 구현 객체를 생성하고 연결하는 책임을 가지는 별도의 설정 클래스 생성한다.
  • 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리됨
• 실제 동작에 필요한 구현 객체를 내부에 생성, 생성한 객체 인스턴스의 참조를 생성자를 통해 주입해준다.
  • new MemberServiceImpl(new MemoryMemberRepository());
  • new OrderServiceImpl(new MemoryMemberRepository(),new FixDiscountPolicy());

문제 해결 결과

• MemberServiceImpl 은 MemoryMemberRepository 를 의존하지 않고 MemberRepository 인터페이스만 의존한다.
• MemberServiceImpl 입장에서는 생성자를 통해 어떤 구현 객체가 주입될지 알 수 없으며 이는 외부에서(AppConfig) 결정된다.

 

클래스 다이어그램

 

회원 객체 인스턴스 다이어그램

 

 

AppConfig 리팩토링

---

Issue

• 현재 클래스 내 중복이 있고 역할에 따른 구현이 명확히 보이지 않아 리팩토링이 필요하다.

해결 방안

• memberRepository() 메서드를 생성하여 new MemoryMemberRepository() 중복을 제거하고 역할과 구현을 구분하여 애플리케이션 전체 구성을 빠르게 파악할 수 있다.

 public MemberRepository memberRepository() {
          return new MemoryMemberRepository();
}

 

스프링으로 전환하기

---

1. AppConfig 스프링 기반으로 변경
   • 스프링 컨테이너에 스프링 빈을 등록하기 위해 AppConfig에 @Configuration 어노테이션을 작성한 후 각 메서드에 @Bean을 붙여준다.
2. MemberApp/OrderApp 스프링 컨테이너 적용
   • 스프링 컨테이너에서 스프링 빈들을 호출할 수 있도록 MemberApp/OrderApp에 각각 아래 코드를 작성한다.

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
OrderService orderService = applicationContext.getBean("orderService",OrderService.class);

 

스프링 컨테이너 동작

• 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정(구성) 정보로 사용하며 @Bean이 적힌 메서드를 모두 호출하여 반환된 객체(참조값)를 스프링 컨테이너에 등록한다.