객체 지향 원리 작용 (메모용)

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

-  위 코드는 인터페이스(DiscountPolicy) 뿐만 아니라 구현체에 의존 >> DIP 위반

- 변경으로 인해 OCP도 위반

 

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

- 인터페이스에만 의존하도록 설계 변경, 구현체가 없기에 실행시 NPE(NullPointerException) 발생

 

- 해결책으로 AppConfig 클래스 생성

(어플리케이션의 전체 동작 방식을 구성하기 위해 구현 객체를 생성하고, 연결하는 책임을 가지는 설정 클래스)

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

- AppConfig는 어플리케이션의 실제 동작에 필요한 구현 객체를 생성

(MemberServiceImpl, MemoryMemberRepository, orderServiceImpl, FixDiscountPolicy)

- AppConfig는 생성한 객체 인스턴스의 참조를 생성자를 통해서 주입

public class MemberServiceImpl implements MemberService {
        private final MemberRepository memberRepository;
        public MemberServiceImpl(MemberRepository memberRepository) {
            this.memberRepository = memberRepository;
}
        public void join(Member member) {
            memberRepository.save(member);
}
        public Member findMember(Long memberId) {
            return memberRepository.findById(memberId);
} }

- 설계 변경을 통해 MemberServiceImpl 은 MemoryMemberRepository를 의존하지 않고 MemberRepository 인터페이스만 의존

- MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다.

- MemberServiceImpl 의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부( AppConfig )에서 결정

- MemberServiceImpl 은 이제부터 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중

 

>> 객체의 생성과 연결은 AppConfig 가 담당, 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리됨

- appConfig 객체는 memoryMemberRepository 객체를 생성하고 그 참조값을 memberServiceImpl 을 생성하면서 생성자로 전달

- 클라이언트인 memberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 우리말로 의존관계 주입 또는 의존성 주입이라 함

 

 

< 사용클래스 예시: MemberApp >

public class MemberApp {
      public static void main(String[] args) {
          AppConfig appConfig = new AppConfig();
          MemberService memberService = appConfig.memberService();
          Member member = new Member(1L, "memberA", Grade.VIP);
          memberService.join(member);
          Member findMember = memberService.findMember(1L);
          System.out.println("new member = " + member.getName());
          System.out.println("find Member = " + findMember.getName());
} }

 

- 위 AppConfig 클래스에는 중복 존재 + 역할에 따른 구현도 잘 안보임 -> 리팩터링 필요

// 리팩터링 후
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();
	  }
}

- new MemoryMemberRepository() 이 부분이 중복 제거

>> 이제 MemoryMemberRepository 를 다른 구현체로 변경할 때 한 부분만 변경하면 됨

- AppConfig 를 보면 역할과 구현 클래스가 한눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악 가능

 

 

< 좋은 객체 지향 설계 5원칙과 관련하여 >

- SRP >> 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당, 클라이언트 객체는 실행하는 책임만 담당

- DIP >> 클라이언트 코드가 DiscountPolicy 추상화 인터페이스에만 의존하도록 코드를 변경, AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입했다. 이렇게해서 DIP 원칙을 따르면서 문제도 해결

- OCP >> AppConfig가 의존관계를 FixDiscountPolicy RateDiscountPolicy 로 변경해서 클라이언트 코드에 주입하므로 클라이언트 코드는 변경하지 않아도 됨

 

 

< 제어의 역전 (IOC : Inversion of Control) >

- 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행

( 구현 객체가 프로그램의 제어 흐름을 스스로 조종, 개발자 입장에서는 자연스러운 흐름 )

- AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당, 프로그램의 제어 흐름은 이제 AppConfig가 가져감

- 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한다.

 

 

< 프레임워크 / 라이브러리 >

- 프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. ( JUnit ex:테스트 코드 )

- 반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리

 

 

< IoC컨테이너 / DI컨테이너 >

- AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다

- 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다.

 

 

< AppConfig 스프링으로 전환 >

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

- AppConfig에 설정을 구성한다는 뜻의 @Configuration 을 붙여줌

- 각 메서드에 @Bean 을 붙여준다. 이렇게 하면 스프링 컨테이너에 스프링 빈으로 등록됨

 

< MemberApp 과 관련한 사용 >

public class MemberApp {
    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig();
//        MemberService memberService = appConfig.memberService();
        ApplicationContext ac = new
AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService =
		ac.getBean("memberService", MemberService.class);
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);
        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("find Member = " + findMember.getName());
} }

 - ApplicationContext 를 스프링 컨테이너라 한다.

- 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용

- @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록( 스프링 컨테이너에 등록된 객체를 스프링 빈이라 함 )

- 스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다. ( memberService , orderService )

- 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 하는데, 스프링 빈은 ac.getBean() 메서드를 사용해서 찾을 수 있다.