스프링 스터디 4주차

새로운 할인 정책 개발

RateDiscountPolicy를 추가한 후 클라이언트인 OrderServiceImpl 코드를 수정

//private final DiscountPolicy discountPolicy=new FixDiscountPolicy();
private final DiscountPolicy discountPolicy=new RateDiscountPolicy();

-> DIP, OCP 위반

 

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

-> 인터페이스에만 의존하게 됨 but NullPointerException 발생 !!

 

=> 해결하기 위해 누군가 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성해줘야함

 

 

 

AppConfig

: 애플리케이션의 전체 동작 방식을 구성 ( = 공연 기획자 역할 )

 

객체의 생성과 연결은 AppConfig가 담당하므로 MemberServiceImpl은 MemberRepository인 추상에만 의존할 수 있다.

= DIP 완성

= 관심사의 분리

 

-> MemberServiceImpl과 OrderServiceImpl은 단지 실행에만 집중하면 된다.

• MemberServiceImpl에는 MemoryMemberRepository 객체의 의존관계가 주입
• OrderServiceImpl -> MemoryMemberRepository, FixDiscountPolicy

 

 

AppConfig 리팩터링

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

    private MemoryMemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

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

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

-> 중복 제거, 역할에 따른 구현이 한 눈에 잘 보임

 

 

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

-> AppConfig 코드만 고치면 된다. = 사용 영역의 코드는 전혀 손댈 필요가 없다.

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

 

※ AppConfig의 등장으로 DIP, OCP 모두 지킬 수 있게 되었다.

 

 

---

제어의 역전 IoC (Inversion of Control)

프로그램의 제어 흐름을 직접 제어하는 것이라 외부에서 관리하는 것

= 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다.

 

프레임워크 : 프레임워크가 코드를 제어하고 대신 실행

라이브러리 : 내가 작성한 코드가 직접 제어의 흐름 담당

 

의존관계 주입 DI (Dependency Injection)

• 정적인 클래스 의존관계 : 실행하지 않아도 분석 가능
• 동적인 객체 인스턴스 의존관계 : 실행 시점에 결정

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

 

---

스프링 컨테어너와 스프링 빈

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext를 스프링 컨테이너라고 함 (ApplicationContext는 인터페이스)

 

스프링 컨테이너의 생성 과정

1. 스프링 컨테이너 생성

2. 스프링 빈 등록

3. 스프링 빈 의존관계 설정 - 준비

4. 스프링 빈 의존관계 설정 - 완료

 

 

 

 

스프링 빈 조회

ac.getBean(빈이름, 타입) or ac.getBean(타입) 사용

@Test
@DisplayName("모든 빈 출력하기")
void findBeanByName(){
    MemberService memberService = ac.getBean("memberService", MemberService.class);
    Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);

}

 

 

스프링 빈 조회 - 동일한 타입이 둘 이상

NoUniqueBeanDefinitionException 예외 발생

->  빈 이름을 지정해서 해결

 

스프링 빈 조회 - 상속관계

부모 타입으로 조회하면, 자식 타입도 함께 조회한다.

자바의 모든 객체는 Object를 상속 받기 때문에 Object타입으로 조회하면, 모든 스프링 빈을 조회할 수 있다.

 

 

BeanFactory와 ApplicationContext

 

BeanFactory

        ↑

ApplicationContext

        ↑

AnnotationConfig, ApplicationContext

 

 

BeanFactory

• 스프링 컨테이너의 최상위 인터페이스
• getBean() 제공
• 우리가 사용하는 대부분의 기능

ApplicationContext

• BeanFactory 기능을 모두 상속받아서 제공
• 부가기능 제공 (MessageSource-언어처리, EnvironmentCapable-환경변수, ApplicationEventPublisher-이벤트, ResourceLoader-리소스)

 

다양한 설정 형식 지원 - 자바 코드 , XML

appConfig.xml 파일 생성 

 

 

 

BeanDefinition = 빈 설정 메타정보

-> 덕분에 스프링은 다양한 설정 형식을 지원해준다.

스프링이 어떤 형식이든지 다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용한다 !!