ocp, di, srp

OCP

• OCP: 소프트웨어 확장에는 열여 있으나, 변경에는 닫혀 있는 것이다.
• AppConfig환경에서 예시

    @Bean
    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();

        return new RateDiscountPolicy();
    }

• 위에서 AppConfig가 의존 관계를 FixDiscountPolicy -> RateDiscountPolicy 변경해서 클라이언트에 주입하니 클라이언트는 변경할 필요가 없다( 변경에 닫혀있다)
• 사용영역(클라이언트 영역)은 변경 할 필요가 없다, 구성영역만 확장하면된다.

DI

• DI 컨테이너 -> 구현 객체를 생성하고, 연결하는 것을 담당한다.

@Configuration
public class AppConfig {


    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public MemberRepository   memberRepository() {
        return new MemoryMemberRepository();
    }
    @Bean
    public OrderService orderService() {

        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();

        return new RateDiscountPolicy();
    }


}

• 위에서 매서드명 memberService, memberRepository, discountPolicy의 이름만 보아도 구성 역할, 구현을 한눈에 볼 수 잇따.
• AppConfig가 구현 객체를 생성하고 연결하는 책임을 담당해서 AppConfig를 DI 의존관계를 주입한다고 한다.

Di(의존관계)의 예시 !

public class MemberServiceImpl implements  MemberService{


    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {

        this.memberRepository = memberRepository;
    }


    @Override
    public void join(Member member) {
        memberRepository.save(member);
    }

    @Override
    public Member findMember(Long memberId) {
        return memberRepository.findById(memberId);
    }
}

• MemberServiceImpl에는 MemoryMemberRepository내용이 없다 오로지 MemoryMemberRepository라는 추상화에만 의존한다.
• MemberServiceImpl는 MemberRepository를 외부에서 주입을 받는 것이다 Di..!!!

SRP

• SRP : 단일 책임원칙, 한 클래스는 하나의 책임만 가져야한다
• 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당한다.
• 클라이언트 객체는 실행하는 책임만 담당.

출처 : 김영한님의 스프링 핵심 원리