[예제] 스프링 없이 좋은 객체 지향 설계하기

'좋은 객체 지향'을 예제를 통해 이해해보자.

역할과 구현을 분리하면 자유롭게 구현 객체를 조립할 수 있다

구현할 기능과 프로세스

---

순수 자바 코드로 구현

[문제 X] SRP(단일 책임 원칙) 수행 사례

OrderService: 할인에 대한 정책은 잘 모르겠다. DiscountPolicy에게 맡긴다.

주문 서비스와 할인 계산의 책임을 분리. 그저 할인액만 받아온다.

→ 할인 관련 코드 변경 시 OrderService는 안 바꿔도 된다.

 

 

[문제] DIP, OCP 위반 사례

• DIP 위반: OrderServiceImpl이 인터페이스 뿐만 아니라 구현체에도 의존
  •  → 구현체 변경 시 코드 변경도 수반
• OCP 위반: 멤버 저장소, 할인 정책을 바꾸는 순간 코드 변경이 수반된다!

 

어떻게 문제를 해결할 수 있을까?

• DIP 위반 -> 추상(인터페이스)에만 의존하게 코드를 변경하면 된다
  

  

  but.. 실제 실행을 해보면 NPE(null pointer exception)가 발생
  

[해결 방안]
누군가 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해주어야 한다!

 

[해결] 관심사의 분리

객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리돼야 한다

• OrderServiceImpl는 인터페이스에 따라 기능만 실행하면 된다.
• memberRepository가 어떤 구현체를 가질지 캐스팅하는 책임을 질 필요는 없다

 

▷ AppConfig 클래스 생성

애플리케이션의 전체 동작 방식을 구성, 설정(config)하기 위해,

구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스

AppConfig가 구현 객체를 생성하고, 연결

AppConfig는 구현 객체를 생성한다

AppConfig는 생성자를 통해 생성한 객체를 주입(연결)해준다

오직 AppConfig만 수정하면 된다!

 

▷ 의존성을 주입받기 위한 생성자 생성

이로써 DIP와 OCP를 지켰다!

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

 

▷ AppConfig를 통해 인스턴스를 생성하고, 주입한다

 

 

관심사의 분리: 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었다

애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리

클라이언트인 OrderServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서

DI(Dependency Injection) 우리말로 의존관계 주입 또는 의존성 주입이라 한다

 

 

[Before & After] 구현체 변경

• Before: 사용처에서 코드 수정

클라이언트의 코드를 수정..

 

• After: AppConfig만 수정하면 된다

설정 클래스의 코드만 수정!

 

 

 

 

---

참고 자료
스프링 핵심 원리(김영한 님)