[Web] Spring 핵심 원리 6 - 관심사의 분리(AppConfig)

서론

- 이전 포스트까지의 코드는 역할과 구현을 분리하여 설계하였다.

- 하지만 새로운 기능의 확장을 위해 결국 OrderServiceImpl의 코드를 변경하였다. (OCP 위반)

- 또한 인터페이스 뿐만 아니라 구현체에도 의존하고 있었다. (DIP 위반)

- 이를 극복하기 위해 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해야 한다 는것을 알게되었다.

- 이번 포스트에선 OCP와 DIP를 지키기위해 "구현 객체를 생성"하고, "연결"하는 책임을 가지는 별도의 설정 클래스 AppConfig를 만들것이다.

 

AppConfig 생성

기존의 MemberServiceImpl은 사진과 같이 MemberRepository 인터페이스와 MemoryMemberRepository 구현체 둘에 모두 의존하고 있다.

이제 이런것들은 모두 AppConfig에서 설정해 줄것이다.

우선 DIP를 위반하는 코드(new MemoryMemberRepository())를 지우고 생성자를 추가해준다.

생성자를 통해 MemberRepository의 구현체가 뭐가 들어갈지 알려줄 것이다.

이제 MemberServiceImpl은 구현체에 의존하지 않고 인터페이스(MemberRepository)에만 의존한다!!

그리고 AppConfig에서 해당 생성자를 통해 어떤 구현체를 넘겨줄지 정해준다.

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

- 이제 MemberServiceImpl은 인터페이스에만 의존한다.

- 생성자를 통해서 어떤 구현체가 주입될지는 알 수 없다. 어떤것이든 들어올 수 있기 때문이다. (다형성)

- 어떤 구현체가 주입될지는 이제 AppConfig가 정해줄것이다. 따라서 MemberServiceImpl은 의존관계에 대한 고민을 AppConfig에게 떠넘기고 오로지 실행에만 집중한다.

 

클래스 다이어그램

 

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

• appConfig 객체는 memoryMemberRepository 객체를 생성하고 그 참조값을 memberServiceImpl 을 생성하면서 생성자로 전달한다.
• 클라이언트인 memberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 우리말로 의존관계 주입 또는 의존성 주입이라 한다.

 

AppConfig 리팩토링

- AppConfig는 역할과 구현이 한눈에 보여야한다.

- 하지만 다음과 같이 기존의 AppConfig는 new MemoryMemberRepository가 중복되며, 역할과 구현이 한눈에 들어오지 않는다.

변경 전

따라서 다음과 같이 리팩토링을 통해 역할과 구현을 구분한다.

변경 후

- 리팩토링을 통해 중복해서 new 하는 코드를 생략하였고, 역할과 구현 클래스가 한눈에 들어온다.

- 이제 새로운 구현체를 갈아 끼울때는 return 값만 변경하면 된다.

 

결론

- AppConfig를 통해 관심사를 확실하게 분리했다.

- 이제 클라이언트 코드를 변경하지 않고 discountPolicy과 memberRepository를 자유자재로 변경할 수 있다!

- 즉, DIP를 만족하게 되었다. (사실 이를 통해 OCP도 지키게 되었다! )

- 전체적인 그림

 

참고

클라이언트와 서버

보통 클라이언트와 서버라면, 웹 브라우저가 클라이언트, 애플리케이션이 서버라고 생각한다.

하지만 클라이언트와 서버는 매우 광범위하게 사용되는 단어이다.

예를 들어 A객체가 B객체의 메서드를 호출하면 A클래스가 클라이언트, B클래스가 서버가 된다.

작게는 이렇게 객체부터, 크게는 웹 브라우저(클라이언트) 서버(애플리케이션 서버) 개념까지 확장된다.