스프링 기본편 복습 - 1

스프링 부트

톰캣 같은 웹 서버를 내장하고 있기 때문에 별도의 웹 서버를 설치하지 않아도 된다.

빌드 구성을 위한 starter 종속성 제공, 외부 라이브러리 자동 구성(버전 자동 맞춤)

운영 환경에서 모니터링 기본 구성, 관례에 의한 간결한 설정

 

스프링의 핵심

자바 언어 기반의 프레임워크로 객체 지향 언어가 가진 특징을 살려내는 프레임워크, 좋은 객체지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

 

객체 지향 프로그래밍

객체들의 모임으로 각각의 객체는 메시지를 주고받고 데이터를 처리한다.

프로그램을 유연하고 변경에 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

 

객체 지향이란 객체의 역할과 구현을 분리하는것을 의미한다.

역할과 구현으로 구분하면 단순, 유연해지며 변경도 편리해진다.

클라이언트는 대상의 역할만 알고 구현 대상의 내부구조, 변경여부, 대상을 변경해도 영향을 받지 않는다.

 

다형성의 본질

인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.

클라이언트를 변경하지 않고 서버의 구현 기능을 유연하게 변경할 수 있다.

 

SOLID

SRP: 단일 책임 원칙

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

중요한 기준은 변경으로 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

 

OCP: 개방-폐쇄 원칙

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

구현 객체의 변경은 스프링이 해준다.

 

LSP: 리스코프 치환 원칙

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 인터페이스를 구현한 구현체를 믿고 사용하려면 이 원칙을 지켜야 한다.

 

ISP: 인터페이스 분리 원칙

특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다.

자동차 인터페이스 -> 운전, 정비 인터페이스로 분리

사용자 인터페이스 -> 운전자 클라이언트, 정비사 클라이언트로 분리

분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음

인터페이스가 명확해지고 대체 가능성이 높아진다.

 

DIP: 의존관계 역전 원칙

프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다. 역할에 의존하게 해야 한다. 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 인터페이스에 의존할 수 있게 스프링이 도와준다.

 

스프링은 DI를 통해 다형성 + OCP, DIP를 가능하게 지원해준다.

클라이언트 코드의 변경 없이 기능 확장 

 

이상적으로는 모든 설계에 인터페이스를 만드는 것이 좋지만 비용을 생각하면 확장 가능성이 있는 곳에는 인터페이스를 도입하고 확장할 가능성이 없다면 구체 클래스를 사용, 꼭 필요한 경우 리팩토링을 통한 인터페이스의 도입이 합리적이다.

 

 

IOC, DI, 컨테이너

 

제어의 역전(IOC)

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

 

의존관계 주입(DI)

애플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것

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

 

 

스프링 컨테이너

ApplicationContext를 스프링 컨테이너라 한다.

 

지금은 대체로 자동으로 등록해주는 편이지만 기존의 AppConfig를 스프링 컨테이너에 수동으로 등록해줄 수도 있다.

public class AppConfig {

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

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

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

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

다음과 같이 스프링 컨테이너에 등록해주고

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

 

기존의 실행 파일을

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("member.getName() = " + member.getName());
        System.out.println("findMember.getName() = " + findMember.getName());
    }
}

 

스프링 컨테이너에서 불러서 실행하면 같은 결과가 나온다.

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("member.getName() = " + member.getName());
        System.out.println("findMember.getName() = " + findMember.getName());
    }
}

 

이렇게하면 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 스프링 빈을 등록한다.

빈 이름을 직접 부여할 수도 있지만 관례적으로 그냥 쓴다.

 

이제 등록된 빈을 찾아보자. 

new AnnotationConfigApplicationContext(AppConfig.class)에서 ac.getBean()을 실행하면 빈 이름으로 빈 객체를 조회할 수 있다.

 

 

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력하기")
    void findAllBean(){
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name = " + beanDefinitionName + " object = " + bean);
        }
    }

그 외 이름, 타입 등등으로 조회할 수 있다.

 

스프링 빈 조회 - 상속관계

스프링 빈 조회시 부모타입으로 조회하면 자식 타입도 함께 조회된다.

그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면 모든 스프링 빈을 조회한다.

 

 

 

빈의 등록은 여러가지 방법으로 할 수 있는데

우리가 많이 쓰는 팩토리 빈 등록 방식, 자바 코드를 통한 방식은 위와 같고 레거시에서 xml을 쓰는 경우 xml 코드를 통해서도 등록할 수 있고 커스텀해서 json 등등 다양한 방식으로 빈을 등록할 수 있다.

이게 가능한 이유는 스프링의 기능들은 인터페이스로 구현 돼 있기 때문에 설정정보에 따라 다른 방법으로 BeanDefinition이라는 빈 메타정보를 생성한다. 이를 가져다 쓰기 때문에 스프링에서는 어떤 방식으로 빈 등록이 됐는지 몰라도 된다.

 

 

 

싱글톤 컨테이너

싱글톤 패턴은 이미 만들어진 객체를 공유해서 추가적 객체를 생성하지 않기 때문에 자원을 효율적으로 사용할 수 있다는 장점이 있다.

하지만,

1. 구현 코드가 많이 들어간다.

2. 의존관계상 클라이언트가 구체 클래스에 의존한다 -> DIP 위반

3. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.

4. 테스트하기 어렵다.

5. 내부 속성을 변경하거나 초기화하기 힘들다

6. private 생성자로 자식 클래스를 만들기 어렵다.

7. 유연성이 떨어진다.

8. 안티패턴으로 불리기도 한다.

같은 수많은 문제가 존재한다.

 

스프링에서는 이를 스프링 컨테이너로 극복했다. 컨테이너에 객체를 하나만 생성해서 관리하기 때문에 스프링 컨테이너는 싱글톤 컨테이너의 역할을 한다.

따라서 지저분한 코드가 들어가지 않고 수많은 위반을 하지 않고도 자유롭게 싱글톤을 사용할 수 있다.

 

이런 싱글톤 방식을 사용할 때 주의할 점이 있다.

싱글톤 방식의 객체 인스턴스를 하나만 생성해서 공유하는 프로그램에서 싱글톤 객체는 상태를 유지하게 설계하면 안된다.

무상태로 설계해야 한다.

- 특정 클라이언트에 의존적 필드가 있으면 안된다.

- 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.

- 읽기만 가능해야 한다.

- 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, TreadLocal 등을 이용해야 한다.

 

@Configuration과 싱글톤

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

다음과 같이 memberRepository를 여러번 호출하는 과정을 거치는데 어떻게 싱글톤이 가능한걸까?

실제로 로그를 찍어보면 각자 한번씩만 찍히는데 이 비밀은 @Configuration에 있다.

@Configuration을 사용하면 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 이용해서 AppConfig클래스를 상속받은 다른 클래스를 만들고 그 다른 클래스를 스프링 빈으로 등록한다.

따라서 @Configuration을 적용하지 않고 @Bean을 적용하면 여러 번의 생성과정을 거쳐서 싱글톤이 보장되지 않는다.