예제에 객체 지향 원리(SOLID) 적용 (Only java)

스프링 핵심 원리 - 기본편 (김영한님)

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8

스프링 핵심 원리 - 기본편 - 인프런 | 강의

수업을 듣고 정리한 글입니다.

 

새로운 할인 정책 개발

고정할인(무조건 1000원 할인)이 아닌 정률 할인(%할인)으로 할인 정책을 바꾼다.

 

애자일 소프트웨어 개발 선언

https://agilemanifesto.org/iso/ko/manifesto.html

애자일 소프트웨어 개발 선언

정률(10%) 할인 정책 만들기

테스트 만들기

- command+shift+T 단축키

Assertions의 assertThat을 import한 후 static 변수로 만들면 assertThat 함수를 바로 작성가능하다.

static 변수

https://wikidocs.net/228

07-03 스태틱(static)

 

사실 정률 할인 정책의 저 코드는 틀렸다..🤨 하지만 테스트는 맞게 돌아간다.

 

 

정률 할인 정책 적용하기

 

• 코드를 적용할때 코드를 수정해야하는 문제 => OCP(변경하지않고 확장 가능)를 위반
• 이 코드는 DIP를 지키지 않았다. 인터페이스가 아닌 구체 클래스(RateDiscountPolicy)에도 의존하고 있다. => DIP 위반

즉 DIP 위반하여 코드 작성 => 수정시에 코드를 변경해야하므로 OCP 위반

DIP를 지키는 코드 작성

구체 클래스가 아닌 인터페이스에만 의존하도록 코드 변경

discountPolicy = new~ 이렇게 구현체를 만들어주지않고 선언만 해주었다. => DIP를 지킴!(인터페이스에만 의존)

 

그러나 실행하면 NULL포인터 Exception이 발생한다.(객체가 없으니 당연)

 

이 문제를 해결하려면 누군가 DiscountPolicy의 구현객체를 대신 생성하여 주입해주어야한다.

 

관심사의 분리

이전까지는 구현체에서 사용할 다른 구현체를 선택하여 생성했지만(RateDiscountPolicy), 이는 역할을 넘어선 책임을 가진 것이므로 적절하지 않다.

 

구현체는 자신의 역할(인터페이스)에만 집중하고, 구현체를 고르는 것은 다른 역할로 구분해야한다. => AppConfig의 등장

 

AppConfig

애플리케이션 설정

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

 

MemberService 구현한 MemberServiceImpl 코드

수정할 코드

MemberRepository를 MemoryMemberRepository로 선택하여 클래스 객체를 생성한 코드이다.

인터페이스가 아닌 구체 클래스에 의존했으므로 변경하자

 

수정 완료

인터페이스만 선언하고, 생성자에서 구체 클래스를 주입하도록 만들었다.(생성자 주입)

 

AppConfig

MemberService의 구현체는 MemberServiceImpl이고, MemberServiceImpl에서 사용하는 repository는 MemoryMemberRepository 이다.

 

=> DIP를 지키는 코드를 작성하였다!

 

 

OrderService를 구현한 OrderServiceImpl

생성자 주입으로 코드를 재작성한다.

 

AppConfig

애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.

 

클래스 다이어그램

AppConfig가 MemberServiceImpl과 MemoryMemberRepository를 만들어서 주입한다.

 

   public MemberService memberService(){
        return new MemberServiceImpl(new MemoryMemberRepository());
    }

MemoryMemberRepository 생성한 것을 MemberServiceImpl에 넘긴다.

 

MemberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 의존관계 주입이라고 한다.

 

실행하기

MemberApp 실행하기

MemberApp에 AppConfig를 생성해서 AppConfig에서 정의한대로 memberService가 생성되게 한다.

 

OrderApp 실행하기

 

 테스트 적용하기

@BeforeEach를 사용해서 테스트케이스 돌릴때마다 appConfig의 memberService가 만들어지게 한다.

테스트 실행

굿

AppConfig 리팩토링

이 구조를 잘 보이게 AppConfig를 리팩토링 하자.

 

AppConfig 코드(수정 전)

리팩토링한 AppConfig 코드

command+option+m: Extract Method

이렇게 하면 1. 중복 제거 2. 역할과 구현 클래스 파악 쉬움 의 장점이 있다.

 

새로운 구조에서 할인 정책 적용

FixDiscountPolicy -> RateDiscountPolicy 로 바꿀때 이제 사용 코드를 안고치고도 잘 적용되는지 확인해보자

이전은 코드를 수정했지만 이제는 구성 부분인 AppConfig 코드만 고치면 된다.

AppConfig 코드 수정

구성을 바꾼후 OrderApp 실행하면

20000원의 10%인 2000원 할인 가격이 제시되는 것을 확인할 수 있다.

 

=> 확장해도 사용 코드 변경은 되지 않는 코드가 되었다! (구성 영역 코드만 바뀜)

=> SRP(단일 책임 원리) ,DIP와 OCP를 지킨 코드