[스프링 기본] 섹션 2. 스프링 핵심 원리 이해1 - 예제 만들기

 

스프링 적용하지 않고 순수한 java만 이용해서 프로젝트 생성해보자.
 

회원 도메인 설계, 개발, 실행과 테스트

MemberServiceImpl이 MemoryMemberRepository를 직접 생성하고 있다.

MemoryMemberRepository를 다른 구현체로 교체한다고 했을 때, 현재 구조는 OCP 원칙을 준수하지 X,  DIP를 준수하는지 X

결론적으로, MemberServiceImpl이 인터페이스뿐 아니라 구현체에도 의존하기에 발생하는 문제점이다.

주문과 할인 도메인 설계, 개발, 실행과 테스트

 
위의 설계에 맞게 강사님이 알려주시는 대로 같이 코딩하면 된다.

 

OrderServiceImpl이 가진 문제점도 MemberServiceImpl이 가진 문제와 동일하다. 추후에 새로운 할인 정책이 추가돼서 변경해야 한다면, 클라이언트 코드인 OverServiceImpl도 수정된다. 그러나, 기능이 확장될 때 기존 코드가 수정되는 것은 OCP 원칙에 위배되며 동시에 구현체에 의존하므로 DIP 또한 위배한다.

 

주문과 할인 도메인 개발

주문 생성 요청이 오면, 회원 정보를 조회하고, 할인 정책을 적용한 다음 주문 객체를 생성해서 반환한다.

메모리 회원 리포지토리와, 고정 금액 할인 정책을 구현체로 생성한다.

 

새로운 할인 정책이 추가되었을 때 문제점이 있는가?

DIP부터 따져보면, 주문 서비스는 DiscountPolity 인터페이스에 의존하지만 구현 클래스에도 의존하고 있어서 DIP를 위반하고 있다.

OCP의 경우, 현재 코드는 기능을 확장하고 적용하면 클라이언트 코드에 영향을 주므로 OCP도 위반한다.

 

해결방안으로는 클라이언트(OrderServiceImpl)가 인터페이스에만 의존하도록 의존 관계를 변경하면 문제는 해결된다.

구현체와 관련된 문제점은 누군가가 OrderServiceImpl에 Discount Policy 구현체를 대신 생성하고 주입해야 한다.

 

글에서 나오는 코드와 내용은 김영한님의 인프런 스프링 기본 강의에서 가져온 것을 알립니다.