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

안녕하세요!

저번 섹션에서 하던 것을 이어 새로운 할인 정책(정률 할인 정책)을 개발해보고 스프링으로 전환을 해보겠습니다!

고고!!

---

1. 새로운 할인 정책 개발 - 정률 할인 정책(RateDiscountPolicy)

저번 섹션에서 했던 것들에 이어 새로운 할인 정책을 확장해보겠습니다.

 

<상황>

• 악덕 기획자: 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액 당 할인하는 정률(%) 할인으로 변경하고 싶습니다.
  예를 들어서 기존 정책은 VIP가 10,000원을 주문하든 20,000원을 주문하든 항상 1,000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10,000원 주문 시 1,000원을 할인해주고, 20,000원 주문 시 2,000원을 할인해주는 것입니다.
• 순진 개발자: 제가 처음부터 고정 금액 할인은 아니라고 하지 않았습니까..
• 악덕 기획자: 애자일 소프트웨어 개발 선언 모릅니까? 계획을 따르기보다 변화에 대응하기를...
• 순진 개발자: ... (하지만 난 유연한 설계가 가능하도록 객체지향 설계 원칙을 준수했지 후후)

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

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

 

순진 개발자가 정말 객체지향 설계 원칙을 잘 준수했을까요?

그리고, 이번에는 주문한 금액의 %를 할인해주는 새로운 정률 할인 정책을 추가해보겠습니다.

RateDiscountPolicy 추가

 

우선 섹션2에서 했던 코드를 다시 켜서 기존에 만들었던 discount라는 패키지에 RateDiscountPolicy라는 클래스를 추가해보겠습니다.

DiscountPolicy라는 인터페이스에 대한 구현체이므로 전에랑 똑같이 implements를 하고 Alt + Enter를 눌러서 메서드 구현(오버라이드)을 해보겠습니다.

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;

public class RateDiscountPolicy implements DiscountPolicy{
    
    private int discountPercent = 10; //10% 할인

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

10% 할인이므로 private int discountPercent = 10;이란 코드를 사용했습니다.

또한, VIP 등급만 할인을 받을 수 있으므로 if문을 사용했습니다.

근데 이 식... 과연 잘 되는 걸까요?

테스트를 해보겠습니다.

 

전에처럼 일일이 테스트 클래스 만들고 하기 힘들잖아요.

그래서 단축키를 이용해볼게요.

윈도우는 ctrl + shift + t, 맥은 command + shift + t를 누르면 

영어로 되어있으면 Create New Test로 뜰 것입니다.

이렇게 뜹니다. 새 테스트 생성을 눌러보겠습니다.

테스트는 JUnit5로 놔두고 클래스 이름은 기존의 RateDiscountPolicy에서 뒤에 Test를 붙힙니다.

그러고 밑에 거는 아무것도 건들지 않고, 확인을 누르면 새로운 테스트 클래스가 생성됩니다.

테스트 클래스 생성된거 보이시나요?

그럼 여기서 테스트문을 만들어보겠습니다.

package hello.core.discount;

import hello.core.member.Grade;
import hello.core.member.Member;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

class RateDiscountPolicyTest {

    RateDiscountPolicy discountPolicy = new RateDiscountPolicy();

    @Test
    @DisplayName("VIP는 10% 할인이 적용되어야 한다.") //한글로 이름을 쓸 수 있음
    void vip_o() {
        //given //테스트 환경을 갖추는 단계, 이런 환경이 주어졌을 때
        Member member = new Member(1L, "memberVIP", Grade.VIP);

        //when //테스트 할 상황을 진행하는 단계, 이렇게 했을 때
        int discount = discountPolicy.discount(member, 10000);

        //then //예상한 대로 잘 작동했는지 테스트, 이렇게 된다
        Assertions.assertThat(discount).isEqualTo(1000);
    }

}

@Test를 사용해서 테스트문을 만듭니다.

그리고, @DisplayName("aa")은 JUnit5 이상부터 지원하는데, ""안에 들어가있는 설명(이름)이 테스트 결과 밑에 뜹니다.

한글로 이름을 쓸 수 있습니다.

그리고, 똑같이 given, when, then을 해줄건데요.

• Member member = new Member(1L, "memberVIP", Grade.VIP);
  • 테스트 전 "memberVIP"라는 멤버형 변수를 생성합니다.
  • 회원 가입 전에 회원 가입 창에 회원의 정보들을 적어놓기만 한 상태와 비슷합니다.
• int discount = discountPolicy.discount(member, 10000);
  • VIP 등급인 이 회원이 10,000원짜리 물건을 구입했을 때 할인되는 금액을 int 변수로 지정했습니다.
• Assertions.assertThat(discount).isEqualTo(1000);
  • Assertions는 JUnit에서 제공하는 테스트 메서드들의 집합 클래스입니다.
    그 중 저희는 비교 대상을 지정할 수 있는 assertThat()을 사용합니다.
  • 저희는 2번째 when에서 나온 변수 discount를 비교 대상에 지정했습니다.
  • 해당 변수(할인되는 금액)가 1000이 맞아야 테스트가 성공합니다.

그럼 테스트를 실행해보겠습니다.

@DisplayName을 통해 이름이 뜨고, 테스트가 성공했다고 뜹니다.

위의 ✔️표시 안 누르면 테스트 결과 밑에 있는 내용 안 뜨더라구요. 저만 그런건지 모르겠는데 암튼 안 나오면 저 체크 표시 눌러보세요. 나올 겁니다.

 

그런데 여기서 중요한건 테스트문은 꼭 실패하는 테스트문도 만들어봐야한다는 것입니다.

실패하는 테스트문도 만들어보겠습니다.

@Test
    @DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다.")
    void vip_x() {
        //given
        Member member = new Member(2L, "memberBASIC", Grade.BASIC);

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

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

아까 테스트문과 코드는 비슷한데 VIP가 아니어야 하므로 등급과 이름을 BASIC으로 바꿔보겠습니다.

이러면 결과가 어떻게 나올까요?

이렇게 오류가 뜹니다.

분명 기대한 값은 1,000인데 실제로는 0이 나와서 오류가 떴다고 나와있습니다.

 

그럼 이 테스트문도 테스트 성공하도록 바꿔보겠습니다.

Assertions.assertThat(discount).isEqualTo(1000);

이 문장에서 1000을 0으로 바꾸면 됩니다.

바꾼 상태에서 테스트 실행을 해보겠습니다.

테스트 성공했습니다.

 

이번엔 테스트문 2개를 한 번에 돌려보겠습니다.

역시나 둘 다 성공한다고 나옵니다.

 

중요한 것이 하나 있는데, 위에 테스트문에서 Assertions 쪽에서 윈도우 기준 Alt + Enter (맥은 옵션 + Enter) 누르고

사진처럼 static import 누르면

Assertions가 사라지고 이렇게 코드가 간결해집니다.

또한, 위의 import문에서 import static org.assertj.core.api.Assertions.*;이 생깁니다.

static import는 자바 기본 문법입니다.

---

2. 새로운 할인 정책 적용과 문제점 - 정률 할인 정책(RateDiscountPolicy)으로 변경

방금 추가한 할인 정책을 애플리케이션에 적용해보도록 하겠습니다.

할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 고쳐야 합니다.

public class OrderServiceImpl implements OrderService{
	...
    //private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
...
}

원래는 정액 할인 정책으로 되어있었기 때문에 FixDiscountPolicy를 사용하였는데, 이제 정률 할인 정책으로 적용할 것이기 때문에 FixDiscountPolicy 자리에 RateDiscountPolicy로 바꿉니다.

그런데 이렇게 했는데 문제점이 발생했습니다.

<문제점 발견>

1. 역할과 구현을 충실하게 분리했습니다. -> OK
2. 다형성도 활용하고, 인터페이스와 구현 객체를 분리했습니다. -> OK

3. OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했습니다. -> 그렇게 보이지만 사실은 X

3-1(중요). DIP: 주문서비스 클라이언트(OrderServiceImpl)는 DiscountPolicy 인터페이스에 의존하면서 DIP를 지킨 것 같은데요..?
-> 클래스 의존 관계를 분석해보면... 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다는 것을 알 수 있습니다.
--> 추상(인터페이스) 의존: DiscountPolicy
--> 구체(구현) 클래스: FixDiscountPolicy, RateDiscountPolicy

3-2(중요). OCP: 변경하지 않고 확장할 수 있다고 했는데요..?
--> 지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 줍니다. 따라서, OCP를 위반합니다.

왜 클라이언트 코드를 변경해야 할까요?

클래스 다이어그램으로 의존관계를 분석해볼 수 있습니다.

 

• 기대했던 의존관계

지금까지 단순히 DiscountPolicy 인터페이스만 의존한다고 생각했습니다.

 

• 실제 의존관계

근데 실제로 까 보면 클라이언트인 OrderServiceImpl이 DiscountPolicy 인터페이스 뿐만 아니라

FixDiscountPolicy인 구체 클래스도 함께 의존하고 있습니다.

실제 코드를 보면 의존하고 있습니다. DIP 위반!!

 

• 정책 변경

그래서, FixDiscountPolicy를 RateDiscountPolicy로 변경하는 순간, OrderServiceImpl의 소스 코드도 함께 변경해야 합니다. OCP 위반!!

Q. 그럼 어떻게 하면 문제를 해결할 수 있을까요?

A. 클라이언트 코드인 OrderServiceImpl은 DiscountPolicy의 인터페이스 뿐만 아니라 구체 클래스도 함께 의존합니다.

그래서, 구체 클래스를 변경할 때 클라이언트 코드도 함께 변경해야 합니다,

근데 이러면 DIP 위반이므로, 추상(인터페이스)에만 의존하도록 의존관계를 변경해야 합니다.

 

인터페이스에만 의존하도록 설계와 코드를 변경해보도록 하겠습니다.

• 인터페이스에만 의존하도록 설계를 변경

public class OrderServiceImpl implements OrderService{
	...
    //private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
    private DiscountPolicy discountPolicy;
...
}

이렇게 인터페이스에만 의존하도록 설계와 코드를 변경했습니다.

하지만, 이렇게 하면 OrderServiceImpl에서 사용할 discountPolicy가 정액 할인 정책일지 정률 할인 정책일지 지정되어 있지 않고, 아예 값을 넣지 않다보니 null 값이 들어갔습니다. (=하고 뒤에 뭔가 없기 때문에)

실제로 실행을 해보면 NPE(Null Pointer Exception)가 발생합니다.

NPE가 왜 터졌을까요?

public class OrderServiceTest {

    MemberService memberService = new MemberServiceImpl();
    OrderService orderService = new OrderServiceImpl();

    @Test
    void createOrder() {
        Long memberId = 1L;
        Member member = new Member(memberId, "시월", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "초콜릿", 10000);
        Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
    }
}

현재 OrderServiceTest 테스트 코드입니다.

테스트 함수인 createOrder()에서 .createOrder 함수가 어디에서 쓰였는지 한 번 들어가볼게요.

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private DiscountPolicy discountPolicy;
    
    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

OrderServiceImpl에서 사용이 되었던 것을 확인할 수 있습니다.

여기에서 int discountPrice = discountPolicy.discount(member, itemPrice);가 문제입니다.

밑에선 discountPolicy가 분명 사용되었는데 아까 저희가 썼던 문장을 보면 discountPolicy가 null임을 알 수 있습니다.

 

이 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해주어야 합니다.

 

=> 지금 현재까지의 상황: DIP는 지켰으나, NPE가 터짐. 

---

3. 문제점 해결 방법 - 정률 할인 정책 있기 전

위에서 문제를 해결하려면 누군가가 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성해주고 주입해줘야 한다고 했습니다.

지금부터 이 역할에 대해서 설명하고 적용해보겠습니다.

 

3-1. 관심사의 분리

애플리케이션을 하나의 공연이라고 생각해보겠습니다.

그리고, 각각의 인터페이스를 배역(배우 역할)이라고 생각해보겠습니다.

그럼 실제 배역 맞는 배우를 선택하는 것은 누가 할까요?

 

로미오와 줄리엣 공연을 하면 로미오 역할을 누가 할지 줄리엣 역할을 누가 할지는 배우들이 정하는 것이 아닙니다.

배우가 연기도 하고 연기할 사람도 구하고 이 모든 것을 다 할 수는 없겠죠.

 

이전 코드는 마치 로미오 역할(인터페이스)을 하는 변우석(구현체, 배우)이 줄리엣 역할(인터페이스)을 하는 여자 주인공(구현체, 배우)을 직접 초빙하는 것과 같습니다.

변우석은 공연도 해야 하고 동시에 여자 주인공도 공연에 직접 초빙해야 하는 "다양한 책임"을 갖고 있습니다.

private DiscountPolicy discountPolicy = new FixDiscountPolicy();

이 코드가 직접 초빙하는 것과 같은 예시입니다.

이전 코드인데 OrderServiceImpl에서는 OrderService와 관련된 로직만 해야하는데, 얘가 DiscountPolicy는 FixDiscountPolicy를 해야 한다고 직접 선택하는 등 구체적인 것까지 하고 있습니다.

 

<관심사를 분리!!>

- 배우는 본인의 역할인 배역을 수행하는 것에만 집중해야 합니다.
- 변우석은 어던 여자 주인공이 선택되더라도 똑같이 공연을 할 수 있어야 합니다.
- 공연을 구성하고, 담당 배우를 섭외하고, 역할에 맞는 배우를 지정하는 책임을 담당하는 별도의 "공연 기획자"가 나올 시점입니다.
- 공연 기획자를 만들고, 배우와 공연 기획자의 책임을 확실히 분리해야 합니다.

 

 

3-2. AppConfig 등장

애플리케이션의 전체 동작 방식을 구성(Config)하기 위해 구현 객체를 생성하고 연결하는 책임을 갖는 별도의 설정 클래스를 만들어보겠습니다.

위에서 얘기한 공연 기획자 같은 역할입니다.

 

한 번 역할 만들어보고 문제점을 해결해보겠습니다.

우선 전체 동작 방식을 구성하는 AppConfig라는 클래스를 hello 폴더 안의 core 패키지 안에 만들어보도록 하겠습니다.

이제 hello 폴더 안의 core 패키지 안이란 말을 hello.core로 줄여서 얘기할게요.

public class AppConfig {

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

AppConfig가 대신 전체적인 작업을 할 것이기 때문에 이렇게 만들어놓습니다.

그리고 일단 MemberServiceImpl로 돌아가보겠습니다.

private final MemberRepository memberRepository = new MemoryMemberRepository();

이 코드는 MemberServiceImpl이 너무 오지라퍼...ㅎ

그래서 저 뒤의 new MemoryMemberRepository()는 지웁니다. AppConfig에서 이런건 다 할거니까요!

 

그리고 MemberServiceImpl에 생성자를 만들어보겠습니다.

public class MemberServiceImpl implements MemberService{

    private final MemberRepository memberRepository;

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

생성자를 통해서 이 MemberRepository의 구현체가 뭐가 들어갈지를 선택합니다.

그리고 아까 만들었던 AppConfig 클래스로 돌아갑니다.

public class AppConfig {

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

여기에서 MemberServiceImpl의 MemoryMemberRepository를 할당합니다.

이렇게 되면 어떻게 될까요?

어디선가 AppConfig를 통해서 memberService()를 불러서 씁니다.

이러면 MemberService 구현체 객체(MemberServiceImpl)가 생성되게 되는데 그 때 MemoryMemberRepository가 

 

MemverServiceImpl에는 MemoryMemberRepository에 대한 코드가 있나요?

없고, 오로지 MemberRepository라는 인터페이스만 있습니다.

이렇게 되면 이제 MemberServiceImpl은 추상화에만 의존하게 되는 것입니다.

DIP를 지키게 되는 것이고, 이제 MemberServiceImpl은 구체적인 상황은 모르게 되는 것입니다.

 

이런 것을 "생성자의 주입"이라고 합니다.

OrderService도 위와 같은 방식으로 해보겠습니다.

AppConfig에서 위에 처럼 이 코드를 추가합니다.

public class AppConfig {
	...
    public OrderService orderService() {
        return new OrderServiceImpl();
    }
}

위에처럼 똑같이 생성자의 주입을 할 것입니다.

OrderServiceImpl 클래스로 돌아가보겠습니다.

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

여기에선 사용하는 필드가 2개였습니다.

위에처럼 new 직접 할당을 과감히 지우고, 생성자를 추가해보겠습니다.

public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
    ...
}

final이 되어있으면 생성자를 통해서 할당이 되어야 합니다.

다시 AppConfig로 돌아가보겠습니다.

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

아까처럼 AppConfig가 OrderServiceImpl의 MemoryMemberRepository와 FixDiscountPolicy를 직접 할당하게 되었습니다.

이렇게 되면 위에처럼 DIP를 철저하게 지키게 된 것입니다.

OrderServiceImpl 입장에서는 discountPolicy에 FixDiscountPolicy가 들어올지 RateDiscountPolicy가 들어올지 모르게 됩니다. 인터페이스인 OrderService에만 의존하게 되는 것이죠.

✏️매우 중요한 내용이기에 다시 한 번 정리를 해보겠습니다.✏️

public class AppConfig {

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

<정리1 - AppConfig>

1. AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성합니다.
- MemberServiceImpl
- MemoryMemberRepository
- OrderServiceImpl
- FixDiscountPolicy

2. AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해줍니다.
- MemberServiceImpl -> MemoryMemberRepository
- OrderServiceImpl -> MemoryMemberRepository, FixDiscountPolicy

참고!!
지금은 각 클래스에 생성자가 없어서 컴파일 오류가 발생합니다. 바로 다음 코드에서 생성자를 만들 예정입니다.

 

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);
    }
}

<정리2 - MemberServiceImpl 생성자 주입>

1. 설계 변경으로 MemberServiceImpl은 MemoryMemberRepository를 의존하지 않습니다.
    단지 MemberRepository 인터페이스에만 의존합니다.
2. MemberServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없습니다.
3. MemberServiceImpl의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정됩니다.
4. MemberServiceImpl은 이제부터 의존 관계에 대한 고민은 외부에 맡기고 실행에만 집중하면 됩니다.

 

회원 클래스 다이어그램

<정리3 - 회원 클래스 다이어그램>

1. 객체의 생성과 연결은 AppConfig가 담당합니다.
2. DIP 완성: MemberServiceImpl은 MemberRepository인 추상에만 의존하면 됩니다.
                    이제 구체 클래스는 몰라도 됩니다.
3. 관심사의 분리: 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리되었습니다.

 

회원 객체 인스턴스 다이어그램

<정리4 - 회원 객체 인스턴스 다이어그램>

1. appConfig 객체는 memoryMemberRepository 객체를 생성하고, 그 참조값을 memberServiceImpl을 생성하면서 생성자로 전달합니다.
2. 클라이언트인 memberServiceImpl 입장에서 보면 의존 관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 즉, 의존관계 주입 또는 의존성 주입이라고 합니다.

 

 

<정리1 - OrderServiceImpl 생성자 주입>

1. 설계 변경으로 OrderServiceImpl은 FixDiscountPolicy를 의존하지 않습니다.
    단지 DiscountPolicy 인터페이스에만 의존합니다.
2. OrderServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없습니다.
3. OrderServiceImpl의 생성자를 통해서 어떤 구현 객체를 주입할지는 오직 외부(AppConfig)에서 결정합니다.
4. OrderServiceImpl은 이제부터 실행에만 집중하면 됩니다.
5. OrderServiceImpl에는 MemoryMemberRepository, FixDiscountPolicy 객체의 의존 관계가 주입됩니다.

AppConfig를 실행해보겠습니다.

기존에 만들었던 MemberApp 클래스에 들어갑니다.

이제 AppConfig가 전체적인 것을 관리하기에 기존의 MemberApp 클래스도 수정해야 합니다.

public class MemberApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        appConfig.memberService();
        //MemberService memberService = new MemberServiceImpl();
        MemberService memberService = appConfig.memberService();
        ...
    }
}

AppConfig에서 MemberService의 구현체를 할당했고, MemberService가 필요한 인자를 잘 넣어줬기 때문에 appConfig.memberService()만 호출해주면 됩니다.

 

마찬가지로 OrderApp 클래스에 들어가서 수정하겠습니다.

public class OrderApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        //MemberService memberService = new MemberServiceImpl();
        //OrderService orderService = new OrderServiceImpl();
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();
        ...
    }
}

위에처럼 수정을 완료하였습니다.

 

실행해볼게요.

MemberApp 실행

OrderApp 실행

둘 다 실행에 성공하였습니다.

 

테스트 코드로도 실행해보겠습니다.

그전에 테스트 코드도 수정해야합니다.

public class MemberServiceTest {
    MemberService memberService;
    //MemberService memberService = new MemberServiceImpl();
    
    @BeforeEach
    public void beforeEach() {
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
    }
    @Test
    void join() {
    	...
    }
}

MemberServiceTest 코드 수정 완료했습니다.

@BeforeEach에 관한 설명은 바로 밑에 나옵니다.

public class OrderServiceTest {
    MemberService memberService;
    OrderService orderService;
    //MemberService memberService = new MemberServiceImpl();
    //OrderService orderService = new OrderServiceImpl();

    @BeforeEach
    public void beforeEach() {
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
        orderService = appConfig.orderService();
    }    
    @Test
    void createOrder() {
    	...
    }
}

@BeforeEach란..

테스트 실행하기 전에 무조건 실행되는 것입니다.

OrderServiceTest까지 수정 완료했고, 테스트 코드를 실행해보겠습니다.

MemberServiceTest 실행

OrderServiceTest 실행

둘 다 실행 성공하였습니다.

3-3. AppConfig 리팩터링

현재 AppConfig를 보면 중복이 있고, 역할에 따른 구현이 잘 보이지 않습니다.😭

기대하는 그림

기대하는 그림은 분명 이랬거든요.

지금 AppConfig에는 역할, 구현 이런게 한 눈에 잘 보이지 않습니다.

 

AppConfig 클래스로 가보겠습니다.

new MemoryMemberRepository() 코드를 선택한 후 Window 기준 ctrl + Alt + M을 눌러줍니다.

(MAC은 Command + Option + M)

추천하는 이름말고 제가 원하는 이름을 사용하기 위해 옆에 옵션 버튼⚙️을 누릅니다.

기타 옵션을 누른 후, 이름을 memberRepository로 하고, 반환 타입은 구체 클래스가 아닌 인터페이스인 MemberRepository로 해보겠습니다.

static 실행은 누르시면 안 됩니다.

그러고 리팩터링을 누르면 중복하는게 있다고 뜹니다.

그럼 가볍게 대체한다고 누르면 됩니다.

 

FixDiscountPolicy도 위의 방법처럼 해보겠습니다.

public class AppConfig {

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

    private MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    } //새로 생긴 부분

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

    private DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    } //새로 생긴 부분
}

해보면 기존의 new MemoryMemberRepository와 new FixDiscountPolicy가 memberRepository()와 discountPolicy()로 바뀌었다는 것을 알 수 있습니다.

 

이렇게 리팩토링을 해 놓으면 역할과 구현이 잘 드러나게 됩니다.

그리고, 나중에 수정을 해야 하면 이 코드만 수정하면 됩니다.

---

4. 새로운 구조와 할인 정책 적용 - 정률 할인 정책으로 변경

처음으러 돌아가서 정액 할인 정책을 정률 할인 정책으로 변경해보도록 하겠습니다.

FixdiscountPolicy를 RateDiscountPolicy로 바꾸는 것입니다.

어떤 부분만 변경하면 될까요?

AppConfig만 변경하면 됩니다!!!

 

AppConfig의 등장으로 밑에 그림처럼 애플리케이션이 크게 사용 영역과 객체를 생성하고 구성하는 영역으로 분리되었습니다.

여기에서 FixDiscountPolicy를 변경하고 싶으면...

밑에 사진처럼 하면 되겠죠.

구성 영역의 코드만 손을 대면 되고, 사용 영역의 코드는 손을 안 대도 되겠죠.

 

구성 영역인 AppConfig의 코드를 한 번 수정해보도록 하겠습니다.

public class AppConfig {
	...
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

	//여길 변경
    private DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

원래 기존 정액 할인 정책을 사용할 때는 코드가 이랬습니다.

정률 할인 정책으로 변경을 하려면 간단합니다.

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

FixDiscountPolicy를 리턴하고 있던 것을 RateDiscountPolicy를 리턴하도록 변경하면 됩니다.

 

테스트를 해보겠습니다.

테스트가 잘 되는 것을 확인할 수 있습니다.

 

정리를 해보자면...

• AppConfig에서 할인 정책 역할을 담당하는 구현을 FixDiscountPolicy에서 RateDiscountPolicy로 변경했습니다.
• 이제 할인 정책을 변경해도 애플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 됩니다.
  • 클라이언트 코드인 OrderServiceImpl를 포함해서 사용 영역의 어떤 코드도 변경할 필요가 없습니다.
• 구성 영역은 당연히 변경됩니다.
  구성 역할을 담당하는 AppConfig를 애플리케이션이라는 공연의 기획자로 생각해보겠습니다.
  공연 기획자는 공연 참여자인 구현 객체들을 모두 알아야 합니다.

---

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

여기서는 크게 SRP, DIP, OCP 이렇게 3가지가 적용되었습니다.

 

5-1. SRP 단일 책임 원칙

한 클래스는 하나의 책임만 가져야 한다.

• 클라이언트 객체는 직접 구현 객체를 생성하고 연결하고 실행하는 다양한 책임을 가지고 있습니다.
• SRP 단일 책임 원칙을 따르면서 관심사를 분리했습니다.
  • AppConfig: 구현 객체를 생성하고 연결하는 책임 담당
  • 클라이언트 객체: 실행하는 책임 담당

 

5-2. DIP 의존 관계 역전 원칙

프로그래머는 추상화에 의존해야하고, 구체화에 의존하면 안 된다.
의존성 주입은 이 원칙을 따르는 방법 중 하나다.

• 새로운 할인 정책을 개발하고, 적용하려고 하니 클라이언트 코드도 함께 변경해야 했습니다.
  • 왜냐하면, 기존 클라이언트 코드 OrderServiceImpl는 DIP를 지키며 DiscountPolicy 추상화 인터페이스에 의존하는 것 같았지만, FixDiscountPolicy 구체화 구현 클래스에도 함께 의존했습니다.
• 클라이언트 코드가 DiscountPolicy 추상화 인터페이스에만 의존하도록 코드를 변경했습니다.
• 하지만... 클라이언트 코드는 인터페이스만으로는 아무 것도 실행할 수 없었습니다.
• AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존 관계를 주입했습니다.
  이렇게 해서 DIP 원칙을 따르면서 문제도 해결했습니다.

 

5-3. OCP

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

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

---

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

6-1. 제어의 역전 IoC (Inversion of Control)

• AppConfig가 등장하기 전...
  • 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고 연결하고 실행합니다.
    한 마디로, 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다고 정의할 수 있습니다. 개발자 입장에서는 자연스러운 흐름이죠.
• AppConfig가 등장한 이후...
  • 구현 객체는 자신의 로직을 실행하는 역할만 담당합니다.
    그리고, 프로그램의 제어 흐름은 이제 AppConfig가 가져갑니다.
    - ex) OrderServiceImpl은 필요한 인터페이스들을 호출하지만, 어떤 구현 객체들이 실행될지 모릅니다.
  • 프로그램의 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있습니다.
    심지어 OrderServiceImpl도 AppConfig가 생성합니다.
  • 그리고, AppConfig는 OrderServiceImpl이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할 수도 있습니다.
    OrderServiceImpl은 그런 사실도 모른 채 묵묵히 자신의 로직을 실행할 뿐...
• 이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라고 합니다.

프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞습니다. (JUnit)

반면에, 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리입니다.

 

 

6-2. 의존관계 주입 DI (Dependency Injection)

OrderServiceImpl은 DiscountPolicy 인터페이스에 의존합니다.

그래서 실제 어떤 구현 객체가 사용될지는 모릅니다.

의존관계는 정적인 클래스 의존관계와 실행 시점에 결정되는 동적인 객체(인스턴스) 의존관계들을 분리해서 생각해야 합니다.

 

• 정적인 클래스 의존관계

클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있습니다.

정적인 의존관계는 애플리케이션을 실행하지 않아도 분석할 수 있습니다.

 

밑의 클래스 다이어그램을 보면 OrderServiceImpl은 MemberRepository, DiscountPolicy에 의존한다는 것을 알 수 있습니다.

클래스 다이어그램

그런데 이러한 클래스 의존관계 만으로는 실제 어떤 객체가 OrderServiceImpl에 주입될 지 알 수 없습니다.

 

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

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

밑에 객체 다이어그램을 한 번 봐보도록 하겠습니다.

애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것을 의존관계 주입이라고 합니다.

객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결됩니다.

 

의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있습니다.

⭐그리고, 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있습니다.

 

 

6-3. IoC 컨테이너, DI 컨테이너

AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 IoC 컨테이너 또는 DI 컨테이너라고 합니다.

그런데, 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라고 합니다.

(어샘블러, 오브젝트 팩토리 등으로 불리기도 합니다.)

 

---

7. 스프링으로 전환하기

지금까지는 스프링 없이 순수한 자바 코드로만 작성했습니다.

이제 드디어 스프링을 사용해보도록 하겠습니다.

 

우선 AppConfig를 스프링 기반으로 바꿔보도록 하겠습니다.

@Configuration
//설정 정보, 구성 정보
public class AppConfig {

    @Bean
    //각 메서드마다 @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 RateDiscountPolicy();
    }
}

AppConfig 함수 위에 @Configuration이라는 annotation을 달았습니다.

@Configuration이란 뭘까요?

한 마디로 설정 정보, 구성 정보를 뜻합니다.

 

그리고, 각 메서드마다 @Bean을 붙혀줍니다.

이렇게 붙혀주면 스프링 컨테이너에 적용이 됩니다.

 

이제 MemberApp 클래스로 이동해보도록 하겠습니다.

public class MemberApp {
    public static void main(String[] args) {
        //AppConfig appConfig = new AppConfig();
        //MemberService memberService = appConfig.memberService();

        //스프링은 ApplicationContext로 시작
        //이게 스프링 컨테이너라고 보면 됨.
        //@Bean을 다 관리해줌
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        //위 문장: AppConfig에 있는 환경 설정 정보를 가지고 @Bean을 스프링 컨테이너에 넣어서 다 관리해줌
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        
        Member member = new Member(1L, "시월", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("findMember = " + findMember.getName());
    }
}

바뀐 부분이 보이시나요?

스프링은 ApplicationContext로 시작합니다. 이것을 스프링 컨테이너라고 보면 돼요.

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); 문장을 해석해보겠습니다.

=> AppConfig에 있는 환경 설정 정보를 가지고 @Bean을 스프링 컨테이너에 넣어서 다 관리를 해준다는 뜻입니다.

 

OrderApp 클래스로 이동해보겠습니다.

public class OrderApp {
    public static void main(String[] args) {
        //AppConfig appConfig = new AppConfig();
        //MemberService memberService = appConfig.memberService();
        //OrderService orderService = appConfig.orderService();

        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);
        
        Long memberId = 1L;
        Member member = new Member(memberId, "시월", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "초콜릿", 20000);

        System.out.println("order = " + order);
    }
}

두 코드를 실행하면 스프링 관련 로그가 몇 줄 실행되면서 기존과 동일한 결과가 출력됩니다.

 

• 스프링 컨테이너

- ApplicationContext를 스프링 컨테이너라고 합니다.

- 기존에는 개발자가 AppConfig를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용합니다.

- 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정(구성) 정보로 사용합니다.

  여기서 @Bean이라고 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록합니다.

  이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 합니다.

- 스프링 빈은 @Bean이 붙은 메서드의 명을 스프링 빈의 이름으로 사용합니다. (memberService, OrderService)

- 이전에는 개발자가 필요한 객체를 AppConfig를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 합니다.

  ⭐스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있습니다.

- 기존에는 개발자가 직접 자바 코드로 모든 것을 했다면 이제부터는 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경되었습니다.

 

Q. 코드가 약간 더 복잡해진 것 같은데 스프링 컨테이너를 사용하면 어떤 장점이 있을까요?

A. 어마어마한 장점이 있습니다. 코드가 지금은 단순하지만 나중에 복잡해지면 개발하기가 힘들어집니다. 스프링 컨테이너가 관리해줌으로써 해줄 수 있는 기능이 어마어마합니다.

---

섹션3도 끝이 났습니다.

드디어 스프링의 첫 걸음을 했네요.

이제부터 본격적으로 스프링 빈과 스프링 컨테이너를 알아볼거에요!

그럼 안녕~~