AppConfig - 애플리케이션 동작 방식을 Configuration !

 

AppConfig

 

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

 

각각의 클래스에서 필요한 클래스의 객체를 생성하고 기능을 수행시켜야 할 때,

구현체를 바로 할당시키면 기능의 변경사항이 있을시에 클라이언트 객체 코드의 변경이 따라올 수 있다.  

그래서 필요한 역할이 바로 동작 방식 구성을 책임지는 "AppConfig" 이다.

 

AppConfig는 애플리케이션 동작에 필요한 구현 객체를 생성해주고, 생성자를 통해서 주입(연결) 해준다.

 

1. Class에서의 변경

 

기존 자바 코드에서는 인터페이스와 클래스를 분리해서 설계를 해놓기는 했지만,

클래스 내부에서 실행하는 객체의 변동이 DIP, OCP 위반 문제를 일으켰다.

 

변경점 :

클래스 내부에 생성자만 구현해 놓는다.

 

orderserviceimpl

discount policy를 교체하고 싶을 때, 기존의 코드로서는 클라이언트인 OrderServieImpl의 코드를 바꿔야 하는 상황이 생긴다. (DIP, OCP 위반)

 

 

MemoryMemberImpl

    //private final MemberRepository memberRepository = new MemoryMemberRepository();

이 부분은 없어져야 마땅하다. 다른 기능으로 변경할 일이 생기면 의존성 문제가 발생할 수 밖에 없다.

 

    public final MemberRepository memberRepository; //member Repository interface만 존재!
    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

이렇게 생성자를 만들어 두면, interface 호출만으로 기능을 수행할 수 있게 된다.

그렇다면 실제 기능을 하는 객체는 어디서 호출해야할까?

 

2. AppConfig 생성

 

AppConfig

 

AppConfig 클래스에서 모든 기능을 "주입"해줄 수 있다.

각 클래스에서 생성자를 만들어 두었기 때문에 AppConfig에서는 객체를 생성 및 주입하는 역할만 하면 된다.

 

이렇게 역할을 분리해두면 의존 문제가 사라지게 된다.

이것을 "의존관계 주입" 이라고 부른다.

 

OrderApp

 

애플리케이션을 실행할 OrderApp에서는 AppConfig를 호출해서 필요한 객체를 불러오기만 하면 된다.

 

 

OrderServiceTest

 

테스트코드도 마찬가지이다. 다만 @BeforeEach 어노테이션을 사용한다.

@BeforeEach 는 각각의 Test 메소드가 실행되기 전에 호출되는 메소드이다. 

 

 

 

+ AppConfig Refactoring

 

AppConfig

 

(cmd+opt+m)

 

- new MemoryMemberRepository()의 중복 제거

 

- MemoryMemberRepository를 다른 구현체로 변경할 때 한 부분만 변경하면 된다.

 

- AppConfig를 보면 역할과 구현 클래스가 한 눈에 들어옴. 애플리케이션 전체 구성을 쉽게 파악할 수 있게 된다.