Spring 핵심 원리 기본편 - 2. DIP 와 OCP

DIP 위반 , OCP 위반

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository = new MemoryMemberRepository();
//    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}

1. DIP ( 추상화(인터페이스)에 의존해라 ) 위반

   : 인터페이스( 추상 )에 의존하고 있지만 구현( 구체 ) 클래스에도 의존하고 있다

2. OCP ( 변경하지 않고 확장 가능 ) 위반

   : FixDiscountPolicy() -> RateDiscountPolicy() 변경시 OrdeServiceImpl의 소스코드 역시 변경

 

DIP 해결 방안

1. 구체화 의존을 없앤다. 

-> null point exception 발생

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private DiscountPolicy discountPolicy;
}

2. 이 문제를 해결하기 위해서는 누군가가 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입 

- AppConfig : 구현 객체를 생성하고 연결하는 책임을 가지는 설정 클래스

                  생성한 객체 인스턴스의 참조를 생성자를 통해서 주입(연결) 해준다

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

public class MemberServiceImpl implements MemberService{

    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

- 오직 인터페이스만 의존

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

- 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중

 

-> DIP 해결

DI ( Dependency Injection ) - 의존관계 주입 또는 의존성 주입

: 의존관계를 마치 외부에서 주입해는 것 같기에

 

OCP 해결

- 정책변경시 클라이언트코드를 포함해서 "사용 영역"의 어떤 코드도 변경할 필요가 없다.

- "구성 영역" ( AppConfig ) 는 당연히 변경

 

 

 

출처 :

인프런 김영한님의 스프링 핵심 원리 - 기본편

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/