23.02.28

<오늘의 복습>

 

- spring

 

🟧 객체 지향 원리 적용

---

관심사의 분리

 

- 실제 실행되는 객체들은 본인의 역할만 수행하도록 해줘야 함

- 어떤 구현체들이 인터페이스에 할당 될지는 '별도의 설정 클래스'를 만들어야 됨!

- 본인에게 할당된 책임을 확실히 분리해야 된다 

 

AppConfig

 

- 어플리케이션의 전체 동작 방식을 구성(config = 설)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들기

- 어플리케이션 전반에 대한 운영을 책임진다고 생각하면 된다

- 어플리케이션 전체를 설정하고 구성한다

➡️ 현재까지 작성한 코드에서 구현체가 구현체를 선택하고 사용하고 있음

 

- AppConfig

public class AppConfig {

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

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

• 생성자를 주입(생성자를 통해서 객체가(new 인스턴스) 생성된게 들어 간다) 
• 생성자를 통해서 MemberRepository에 어떤 구현체가 들어갈지를 선택
• final → 기본으로 하든 생성자를 할당하든 둘 중에 한가지로!
• 생성한 객체 인스턴스의 참조(인스턴스)를 생성자를 통해 주입(연결)해 준다
  • MemberServiceImpl → MemoryMemberREpository
  • OrderService → MemoryMemberRepository, FixDiscountPolicy 
• return new MemberServiceImpl(new MemoryMemberRepository()); ➡️ MemberServiceImpl은 MemoryMemberRepository를 사용할 것이다 (라는 뜻) 

- MemberServiceImpl 수정

public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) { // 생성자 생성
        this.memberRepository = memberRepository;
    }

• 생성자를 통해서 memberRepository에 구현체가 뭐가 들어갈지 선택  
• AppConfig를 통해서 memberService를 호출해서 사용 
• MemberServiceImpl에 MemberRepository에 대한 코드 x ➡️ MemberRepository라는 인터페이스만 있다(추상화에만 의존한다)
• MemberServiceImpl → 구체적인 것은 전혀 모름! (어떤 객체가 들어올지?)
• 설계 변경으로 MemberServiceImpl은 MemoryMemberRepository를 의존하지 않음! → MemberRepository 인터페이스만 의존함
• MemberServiceImpl의 생성자를 통해 어떤 구현 객체를 주입할지는 ➡️ 오직 외부(AppConfig)에서 결정됨 
• MemberServiceImpl은 의존관계에 대한 고민은 외부에 맡기고 실행에만 집중!

- OrderServiceImpl 수정

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

• 사용하는 필드가 2개 - MemberRepository, discountPolicy
• final - 기본으로 할당을 하든, 생성자로 할당을 하든 → 두 가지중에서 선택
• this를 통해 값이 넘어가면서 할당된다
• discountPolicy에서 fix가 들어올지 rate가 들어올지 모른다 → OrderServiceImpl (createOrder()로지만 실행하면 됨) 
• 설계 변경으로 OrderServiceImpl은 FixDiscountPolicy를 의존 x ➡️ DiscountPolicy 인터페이스만 의존함
• OrderServiceImpl → 어떤 생성자를 통해 구현 객체가 들어올지 모름
• OrderServiceImpl 생성자를 통해 어떤 구현 객체를 주입할지는? ➡️ AppConfig에서 결정
• OrderServiceImpl  : 실행에만 집중! 
• OrderServiceImpl는 : MemoryMemberRepository , FixDiscountPolicy객체의 의존관계가 주입됨 

➡️ DIP를 지키고 있음 - 인터페이스만 의존함, 구체적인 생성자를 주입시켜줘야 한다

 

• 객체의 생성, 연결 ➡️ AppConfig가 담당
• DIP 완성 : MemberServiceImpl은 MemberRepository인 '추상'에만 의존하면 됨, 구체 클래스를 몰라도 된다
• 관심사 분리 : 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리됨
• appConfig 객체는 memoryMemberRepository를 생성  →그 참조값을 memberServiceImpl을 생성하면서 생성자로 전달
• 클라이언트인 memberServiceImpl입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI - 우리말로 '의존관계 주입 or 의존성 주입' 이라고 한다
  
  • 의존은 관계가 중요함!

인텔리제이 기능

• 표시한 코드에 문제가 있다는 뜻!

- MemberApp (테스트)

public class MemberApp {

    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        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());
    }
}

• AppConfig를 만들어야 된다
• appconfig.memberService()가 필요하다(인터페이스 호출) ➡️ memberServiceImpl이 들어감
• 기존에는 → MemberServiceImpl을 직접 메인 메서드에서 생성 → memoryMemberRepository를 생성 
• 위 코드에서는 appConfig에서 모든 결정을 한다

테스트 결과

• 테스트가 잘 실행되는 것을 볼 수 있음

- OrderApp 테스트 실행

public class OrderApp {

    public static void main(String[] args) {

        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();

        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(
                memberId, "itemA", 10000);

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

• 더이상 구체 클래스에 의존할 필요 x
• 인터페이스에만 의존 

OrderApp 테스트 실행

• 실행이 되는 것을 확인 

- 테스트 코드 수정!

public class MemberServiceTest {

    MemberService memberService;

    @BeforeEach
    public void beforeEach() { // 실행하기 전에 돌릴꺼야
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
    }

 

public class OrderServiceTest {

    MemberService memberService;
    OrderService orderService;

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

모든 테스트

• 모든 테스트가 성공하는 걸 확인할 수 있음

 

 

 

 

 

 

 

---

<출처 - 인프런(스프링 핵심 원리 - 기본편) , 김영한 >

- 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/dashboard

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

- (스프링 핵심 원리 - 기본편) 강의를 듣고 학습을 위해 작성했습니다.