스프링 핵심 원리 이해 ✌

Yerim·2021년 8월 17일
0

Spring

목록 보기
3/9
post-thumbnail

✔ Inflearn 강의 수강 내용 정리글입니다!


객체 지향 원리 적용

본 강의에서는 이전에 구현한 프로젝트 예제에 객체 지향 원리를 적용한다

새로운 할인 정책 개발과 문제점

💡 새로운 할인 정책 개발

  • 이전 강의에서 구현했던 FixDiscountPolicy 에서 RateDiscountPolicy 로 할인 정책 변경
public class RateDiscountPolicy implements DiscountPolicy {

 @Override
 public int discount(Member member, int price) {
 }
}

할인 정책 DiscountPolicy 인터페이스의 새로운 구현 클래스 RateDiscountPolicy 생성

마찬가지로 테스트 코드를 작성하여 새로운 할인 정책 RateDiscountPolicy 이 제대로 동작하는지 확인

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
 assertThat(discount).isEqualTo(1000);
 }
 @Test
 @DisplayName("VIP가 아니면 할인이 적용되지 않아야 한다.")
 void vip_x() {
 //given
 Member member = new Member(2L, "memberBASIC", Grade.BASIC);
 //when
 int discount = discountPolicy.discount(member, 10000);
 //then
 assertThat(discount).isEqualTo(0);
 }
}

@DisplayName 어노테이션을 사용하면 클래스와 메서드에 이름을 붙여줄 수 있다

💡 새로운 할인 정책과 문제점

  • 새로운 할인 정책을 적용하기 위해서는 OrderServiceImpl 코드를 고쳐야 한다
public class OrderServiceImpl implements OrderService {
// private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
 private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}
  • 역할과 구현을 분리하기 위하여 다형성을 활용하여 인터페이스와 구현 클래스를 분리하였다
  • 그러나 OCP, DIP와 같은 원칙을 지키지 못했다
  • OCP : 할인 정책 변경의 기능 확장을 위해서는 클라이언트(OrderServiceImpl ) 코드를 변경해야 한다
  • DIP : 클라이언트 코드가 추상(인터페이스, DiscountPolicy ) 뿐만 아니라 구체(구현, RateDiscountPolicy & FixDiscountPolicy )에도 의존하고 있다


    할인 정책 변경 시 클라이언트인 OrderServiceImpl 이 인터페이스와 구현 클래스 두가지에 모두 의존하고 있다

문제 해결을 위하여 인터페이스에만 의존하도록 코드 변경

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

구현체가 없는데 어떻게 코드를 실행할까?
누군가 클라이언트에 구현체를 대신 생성하고 주입


관심사의 분리

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

코드 중복을 제거하고 역할이 잘 보이도록 리팩터링 한 코드

  • AppConfig는 실제 동작에 필요한 구현 객체를 생성
  • 생성한 객체 인스턴스의 참조를 생성자를 통해 연결(주입)

MemberServiceImpl, OrderServiceImpl 생성자 주입

  • MemberServiceImpl 생성자 주입
public class MemberServiceImpl implements MemberService {

 	private final MemberRepository memberRepository;
    
 	public MemberServiceImpl(MemberRepository memberRepository) {
    		this.memberRepository = memberRepository;
 	}
 }
  • 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;
 	}
}
  • 설계 변경으로 클라이언트 코드들은 구현 객체에 의존하지 않고 인터페이스에만 의존한다
  • 어떤 구현 객체를 주입할지는 외부(AppConfig)에서 결졍

💡 AppConfig 실행

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

AppConfig를 통해 관심사 분리!
AppConfig가 구현 클래스 선택
MemberServiceImpl , OrderServiceImpl는 기능 실행 책임만!

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

  • AppConfig의 등장으로 애플리케이션이 사용 영역객체를 생성하고 구성하는 영역으로 분리


    구성 영역만 영향을 받고 사용 영역은 전혀 영향을 받지 않는다

  • AppConfig에서 구현 객체를 변경하면 된다
  public DiscountPolicy discountPolicy() {
	// return new FixDiscountPolicy();
 	return new RateDiscountPolicy();
  }

좋은 객체 지향 설계의 5가지 원칙

SRP, DIP, OCP 적용

💡 SRP - 단일 책임 원칙

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

  • SRP 단일 책임 원칙을 따르면서 관심사 분리
  • 구현 객체 생성과 연결 책임은 AppConfig가 담당
  • 클라이언트 객체는 실행하는 역할만 담당

💡 DIP - 의존관계 역전 원칙

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

  • 클라이언트 코드가 추상(인터페이스)에만 의존하도록 코드 변경
  • AppConfig가 클라이언트 코드 대신 구현 객체(구체)를 생성하여 의존관계를 주입

💡 OCP

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

  • AppConfig가 의존관계를 변경하여 클라이언트에 주입하므로 클라이언트 코드는 변경하기 않아도 된다
  • 소프트웨어 요소를 새롭게 확장해도 사용 영역의 변경은 닫혀있다

IoC, DI, 그리고 컨테이너

💡 제어의 역전 IoC(Inversion of Control)

  • AppConfig 사용 이후 구현 객체는 자신의 로직을 실행하는 역할만 담당
  • 프로그램에 대한 제어 흐름에 대한 권한은 AppConfig가 가지고 있다
  • 프로그램 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것제어의 역전(IoC)라고 한다

💡 프레임워크 vs 라이브러리

  • 내가 작성한 코드를 제어하고 다신 실행하면 프레임워크
  • 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 라이브러리

💡 의존관계 주입 DI(Dependency Injection)

  • 정적인 클래스 의존관계

    • 클래스가 사용하는 import 코드만 보고 파악 가능
    • 프로그램을 실행하지 않고도 분석 가능
    • 실제 어떤 구현 객체가 주입될지 알 수 없다
  • 동적인 객체 인스턴스 의존 관계

    • 어플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존관계
    • 실행 시점에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 의존 관계 연결 ➡ 의존관계 주입
    • 의존관계 주입 사용 시 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스 변경 가능
    • 의존관계 주입 사용 시 정적인 클래스 의존관계를 변경하지 않고 동적인 객체 인스턴스 의존관계 변경 가능

💡 IoC 컨테이너, DI 컨테이너

  • AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는것 ➡ IoC 컨테이너 또는 DI 컨테이너

스프링으로 전환하기

  • AppConfig에 스프링 컨테이너 적용
@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();   // 할인 정책 변경
    }

}

@Configuration : 설정을 구성한다
@Bean : 스프링 컨테이너에 스프링 빈으로 등록

  • MemberApp에 스프링 컨테이너 적용
public class MemberApp {

    public static void main(String[] args) {
        
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
}
  • OrderApp에 스프링 컨테이너 적용
public class OrderApp {

    public static void main(String[] args) {

        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);
}

💡 스프링 컨테이너

  • ApplicationContext : 스프링 컨테이너
  • 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용
  • @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록 ➡ 스프링 빈
  • 스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있다

📍 코드가 좀 더 복잡해진 것 같은데, 스프링 컨테이너를 사용하면 어떤 이점이 있을까?


[출처 - Inflearn : 스프링 핵심 원리 - 기본편] 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

profile
Backend-Developer

0개의 댓글