[스프링 핵심 원리 - 기본편] #3. 스프링 핵심 원리 이해2 - 객체 지향 원리 적용

[chaelink]

섹션 3. 스프링 핵심 원리 이해2 - 객체 지향 원리 적용

1. 새로운 할인 정책 개발

**기존의 정액 할인 정책이 정률 할인 정책으로 변경되는 상황 발생 **

RateDiscountPolicy 구현체 생성

public class RateDiscountPolicy implements DiscountPolicy {

    private int discountPercent = 10;

    @Override
    public int discount(Member member, int price) {
        if (member.getGrade() == Grade.VIP) {
            return price * discountPercent/100;
        }
        else {
            return 0;
        }
    }
}

ctrl+shift+t : create new Test 작성중인 코드에 대한 테스트파일 바로 생성 가능

RateDiscountPolicyTest 생성
성공하는 테스트와 실패하는 테스트 모두 점검해보는 것이 중요하다

class RateDiscountPolicyTest {
    RateDiscountPolicy discountPolicy = new RateDiscountPolicy();

    @Test
    @DisplayName("vip는 10%할인이 적용되어야 한다.")
    void vip_o() {
        //given
        Member member = new Member(1L, "vipmember", Grade.VIP);

        //when
        int discount = discountPolicy.discount(member,10000);

        //then
        Assertions.assertThat(discount).isEqualTo(1000);
    }

    @Test
    @DisplayName("vip는 10%할인이 적용되지않아야 한다.")
    void vip_x() {
        //given
        Member member = new Member(2L, "basicmember", Grade.BASIC);

        //when
        int discount = discountPolicy.discount(member,10000);

        //then
        Assertions.assertThat(discount).isEqualTo(1000);
    }
}

2. 새로운 할인 정책 적용과 문제점

새로운 할인 정책을 적용하려면 클라이언트인 OrderServiceImpl을 수정해야 하는데 여기서 문제가 발생한다.

DIP 위반
OrderServiceImpl이 인터페이스인 DiscountPolicy, 구현체인 FixDiscountPolicy에 모두 의존하고 있다.

OCP 위반
기능을 변경하려면 클라이언트 코드인 OrderServiceImpl을 변경해야한다.

해결 방안
인터페이스에만 의존하도록 코드를 변경한다.
=> 구현체가 없는 문제 발생(null pointer exception)

3. 관심사의 분리

AppConfig
구현 객체를 생성하고, 연결하는 책임을 가진다.

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

    public OrderService orderService() {
        return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
    }
}

4. AppConfig 리팩터링

• AppConfig에 중복이 없도록 수정
• 역할과 구현이 한눈에 들어온다
• AppConfig에서도 전체적인 구조를 확인할 수 있다

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

    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }
    
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

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

정액 할인 정책을 정률 할인 정책으로 변경하려 한다. AppConfig만 변경하면 된다.

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

객체를 생성하고 구성하는 영역인 AppConfig만 수정하여 변경을 완료하였다.

6. 전체 흐름 정리

새로운 할인 정책 개발, 적용시 문제점 발생
다형성 덕분에 새로운 할인 정책 코드를 개발하는 것에는 문제가 없었다. 그러나 새로운 할인 정책을 적용하려하니 클라이언트 코드도 변경해야하는 DIP 위반 발생

관심사의 분리
구현 객체를 생성하고 연결하는 기획자 역할의 AppConfig 등장, 애플리케이션을 사용 영역과 구성 영역으로 나누었다.

7. 좋은 객체 지향 설계의 5가지 원칙의 적용

SRP 단일 책임 원칙

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

DIP 의존 관계 원칙

• 추상화에 의존해야지, 구체화에 의존하면 안된다.
• 기존 코드는 클라이언트 코드인 OrderServiceImpl 이 DiscountPolicy 와 FixDiscountPolicy 모두를 의존하는 문제가 있었다.
• 클라이언트 코드는 추상화 인터페이스만 의존하도록 코드 수정
• AppConfig가 클라이언트에 의존 관계를 주입하도록 한다.

OCP 개방 폐쇄 원칙

• 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 애플리케이션을 사용 영역과 구성 영역으로 나눈다.
• 사용 영역의 변경은 닫혀 있다.
• 구성 영역만 변경하여 수정사항을 반영할 수 있다.

8. IoC, DI, 그리고 컨테이너

IoC 제어의 역전

• 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라고 한다.
• 프로그램의 제어 흐름을 AppConfig가 가져간다.
• 예를 들어, OrderServiceImpl은 필요한 인터페이스를 호출하지만 어떤 구현 객체들이 실행될 지는 모른다.

DI 의존 관계 주입

• 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체 의존 관계를 분리해야 한다.
• 애플리케이션 실행 시점에 외부에서 실제 구현 객체가 생성되고, 클라이언트 서버와 실제 의존관계가 연결 되는 것을 의존 관계 주입이라 한다.
• 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
• 정적 클래스 의존 관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

정적인 클래스 의존 관계

• 애플리케이션을 실행하지 않고도 분석 가능하다.
  

동적인 객체 인스턴스 의존 관계

• 애플리케이션 실행 시점에 생성된 실제 객체 인스턴스의 참조가 연결된 의존 관계
  

IOC, DI 컨테이너
AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것
의존 관계 주입에 초점을 맞추어 주로 DI컨테이너라고 부른다.
혹은 어셈블러, 오브젝트 팩토리 등으로 불리기도 한다.

9. 스프링으로 전환하기

@configuration
AppConfig에 설정을 구상한다 것을 알려주는 역할

@bean
스프링 컨테이너에 스프링 빈을 등록하는 역할

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

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

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

스프링 컨테이너 ApplicationContext

• 기존에는 AppConfig를 사용해서 객체를 생성하고 DI 했지만, 이제는 스프링 컨테이너를 사용한다.
• @configuration 이 붙은 AppConfig를 설정 정보로 사용한다. 여기서 @bean이 붙은 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다.
• 이제는 스프링 컨테이너에 스프링 빈을 등록하고, 필요한 스프링 빈은 찾아서 사용한다.

public class MemberApp {
    public static void main(String[] args) {
        
        // AppConfig appConfig = new AppConfig();
        // MemberService memberService = appConfig.memberService();
        
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);
        Member findMember = memberService.findMember(1L);
        
        System.out.println("new member = " + member.getName());
        System.out.println("find Member = " + findMember.getName());
    }
}