객체 지향 원리 적용(3)

💡 새로운 구조와 할인정책 적용

객체 지향 원리 적용(2)에서 사용 영역의 코드와 구성영역의 코드 AppConfig를 만들었다.이번에는 할인 정책을 변경하려 하는데 기존에는 사용영역에서 모든 코드를 변경했다면 이제는 사용 영역의 코드는 전혀 손댈 필요 없이 구성 영역인 AppConfig에서만 간단히 수정해 완성해본다.

할인 정책 코드를 변경할때에는 사용 영역의 코드는 수정할 필요 없이 구성 영역의 AppConfig에서만 수정해주면 된다. 이렇게 OCP, DIP 같은 객체지향 설계 원칙을 모두 지킨 코드를 완성할 수 있다.

[AppConfig]

public class AppConfig {

    public MemberRepository memberRepository(){
        return new MemoryMemberRepository();
    }

    public DiscountPolicy discountPolicy(){
//        return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

💡 관심사의 분리

애플리케이션을 하나의 공연으로 생각해보면 기존에는 클라이언트가 의존하는 서버 구현 객체를 직접 생성하고 실행했다. 이런 코드는 OCP, DIP 원칙을 위반하기 때문에 별도의 공연 기획자인 AppConfig를 생성했으며 AppConfig는 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 갖는다.

💡 AppConfig

구성 정보에서 역할과 구현을 명확하게 분리했으며 중복된 코드를 제거했다. AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는
영역으로 분리되었으며 할인 정책을 변경해도 AppConfig가 있는 구성 영역만 변경하면 되기 때문에 사용영역의 코드는 수정할 필요가 없다.

이 글은 김영한님의 스프링 핵심 원리 강의를 듣고 정리한 내용입니다.

💡 좋은 객체 지향 설계의 원칙

SRP 단일 책임 원칙

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

DIP 의존관계 역전 원칙
“추상화에 의존해야지, 구체화에 의존하면 안된다"

• 클라이언트 코드가 추상화 인터페이스에만 의존하도록 코드를 변경한다.
• AppConfig에서 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트
  코드에 의존관계를 주입한다. 이렇게해서 DIP 원칙을 따르는 코드를 만들 수 있다.

OCP
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다

• 애플리케이션을 사용 영역과 구성 영역으로 나눈다.
• AppConfig가 의존관계를 FixDiscountPolicy RateDiscountPolicy 로 변경해서 클라이언트
  코드에 주입하므로 클라이언트 코드는 변경하지 않아도 된다.
• 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀있게 된다.

이 글은 김영한님의 스프링 핵심 원리 강의를 듣고 정리한 내용입니다.