코딩코딩해

서블릿(Servlet)이란?

자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램을 말한다. 서블릿은 웹 요청과 응답의 흐름을 간단한 메서드 호출만으로 체계적으로 다룰 수 있게 해준다.

사용 방법

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {

	@Override
    protected void service(HttpServletRequest request, HttpServletResponse response) {
    	// 애플리케이션 로직
    }
}

• HTTP 프로토콜 서비스를 지원하는 javax.servlet.http.HttpServlet 클래스를 상속
• urlPatterns으로 지정한 /hello의 URL이 호출되면 service 메서드가 실행
• HttpServletRequest을 통해 HTTP 요청 정보를 꺼내서 사용
• HttpServletResponse객체에 HTTP 응답 정보를 입력

서블릿 특징

• 클라이어트의 요청에 대해 동적으로 작동하는 웹 애플리케이션 컴포넌트이다.
• HTML을 사용하여 요청에 응답한다.
• 자바 Thread를 이용하여 동작한다.
• MVC 패턴에서 컨트롤러로 이용된다.
• UDP보다 처리 속도가 느리다.
• HTML 변경 시 서블릿을 재컴파일해야 하는 단점이 있다.

서블릿 컨테이너(Servlet Container)

톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너이라고 부른다. 서블릿 컨테이너란 서블릿 객체를 자동으로 생성하고, 호출하고, 서블릿의 생명주기까지 다 관리해주는 컨테이너다. 서블릿 컨테이너는 서블릿 객체를 싱글톤으로 관리하며, 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용한다. 하지만 Request,(요청) Response(응답) 객체는 요청마다 새로 생성된다.

주요 기능

• 서블릿 생명주기 관리
• 웹 서버와의 통신 지원
• 동시 요청을 위한 멀티 쓰레드 처리 지원 및 관리
• 선언적인 보안 관리

서블릿 동작 방식

1. 클라이언트가 URL을 입력하면 HTTP 요청이 Servlet Catainer로 전송한다.
2. 서블릿 컨테이너는 관련된 Servlet을 메모리에 올린다.
3. 서블릿 컨테이너는 web.xml을 참조하여 해당 Servlet에 대한 Thread를 생성하고, HttpServletRequest(요청 정보가 저장된), HttpServletResponse(비어 있는) 객체를 생성하여 전달한다.
4. Thread는 Servlet의 service() 메서드를 호출한다.
5. service() 메서드는 요청에 맞게 doGet() 또는 doPost() 메서드를 호출한다.
6. doGet() 또는 doPost() 메서드는 인자에 맞게 생성된 동적 페이지를 HttpServletResponse 객체에 담아 응답을 보낸다.
7. 응답을 처리하면 생성된 Thread를 종료하고, HttpServletRequest와 HttpServletResponse 객체를 소멸시킨다.

이전 글 보러가기:)

2022.10.25 - [Spring] - 웹 서버(Web Server) & 웹 애플리케이션 서버(WAS)

참고

https://mangkyu.tistory.com/14

https://coding-factory.tistory.com/742

김영한님의 [스프링 MVC 1편]을 보고 작성한 글입니다:)

해당 글에서는 Web Server와 WAS에 대해서 알아보고, 왜 Web Server와 WAS를 구분해서 사용해야 하는지 알아본다.

웹 서버(Web Server)

• HTTP 기반으로 동작하며, 클라이언트의 요청을 서비스하는 기능을 담당한다.
• 기능1
  • 클라이언트 요청을 받아 정적인 컨텐츠 제공한다.
    • 정적 컨텐츠: 정적 HTML, CSS, JS, 이미지, 영상 등
  • 정적 컨텐츠는 WAS를 거치지 않고 바로 응답 가능하다.
• 기능2
  • 클라이언트가 동적인 컨텐츠 제공을 요청하면, 그 요청을 WAS에 전달하고,
  • WAS가 처리한 결과를 클라이언트에게 전달한다.
• 예) NGINX, APACHE

웹 애플리케이션 서버(WAS; Web Application Server)

• HTTP 프로토콜을 기반으로 동작하며, 웹 서버 단독으로 처리할 수 없는 DB조회나 다양한 로직 처리를 요구하는 동적 컨테츠를 제공한다.
• 주요기능
  
  • 프로그램 코드를 실행해서 구현된 비지니스 로직 수행한다.
  • 비지니스 로직을 통해 만들어진 동적 컨텐츠 제공한다.
  • 서블릿, JSP 구동환경 제공하며, "웹 컨테이너(Web Container)" or "서블릿 컨테이너(Servlet Container)" 라고도 불린다.
  • 웹 서버 기능도 포함한다. (정적 컨텐츠 제공 가능)
• 예) Tomcat, Jetty, Undertow

💡 Web Server와 WAS를 구분하는 이유

WAS가 Web Server의 기능도 모두 수행하면 되지 않을까?! 라고 생각할 수 있다.

만약 WAS만 사용한다면, 밑에와 같은 문제들이 발생한다.

1. WAS가 정적 콘텐트 요청 처리까지 담당하여 서버 과부하가 올 수 있다.
2. 정적 컨텐츠 처리 때문에 동적 컨텐츠 처리 속도가 느려질 수 있다.
3. WAS 장애시 오류 화면 노출이 불가능하다.

따라서, Web Server를 WAS를 분리해서 사용해야 한다.

Web Server를 WAS와 앞에 두고 필요한 WAS들을 Web Server에 플러그인 형태로 설정하여 사용하면 효율적인 분산 처리가 가능하다. 

Web Service Architecture

웹 시스템 구성 - WEB, WAS, DB

• 정적 컨텐츠는 Web Server를 통해 WAS까지 가지 않고 앞단에서 빠르게 처리된다.
• Web Server는 비지니스 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임한다.
• WAS는 DB조회와 같은 중요한 로직 처리를 전담한다.
• Load Balancing으로 효율적인 리소스 관리를 할 수 있다.
  • 정적 리소스가 많이 사용되면 Web 서버 증설
  • 애플리케이션 리소스가 많이 사용되면 WAS 증설
• WAS, DB 장애가 발생하면  Web Server가 오류 화면을 제공한다.

동작 과정

1. Web Server는 웹 브라우저 클라이언트로부터 HTTP 요청을 받는다.
2. Web Server는 클라이언트의 요청(Request)을 WAS에 보낸다.
3. WAS는 관련된 Servlet을 메모리에 올린다.
4. WAS는 web.xml을 참조하여 해당 Servlet에 대한 Thread를 생성한다. (Thread Pool 이용)
5. HttpServletRequest와 HttpServletResponse 객체를 생성하여 Servlet에 전달한다.
   • Thread는 Servlet의 service() 메서드를 호출한다.
   • service() 메서드는 요청에 맞게 doGet() 또는 doPost() 메서드를 호출한다.
6. doGet() 또는 doPost() 메서드는 인자에 맞게 생성된 적절한 동적 페이지를 Response 객체에 담아 WAS에 전달한다.
7. WAS는 Response 객체를 HttpResponse 형태로 바꾸어 Web Server에 전달한다.
8. 생성된 Thread를 종료하고, HttpServletRequest와 HttpServletResponse 객체를 제거한다.

다음 글 보러가기:)

2022.10.25 - [Spring] - [Web] 서블릿(Servlet)

참고

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

https://devmoony.tistory.com/113

김영한님의 [스프링 핵심 원리 - 기본편]을 보고 작성한 글입니다:)

빈 스코프(Bean Scope)란?

빈 스코프는 빈이 스프링 컨테이너에서 존재할 수 있는 범위를 말한다.

여기서 알아야 할 점은 스프링 빈의 생명주기다. 생명주기는 다음과 같다.

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 설정 -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 스프링 종료

빈 스코프의 종류

• 싱글톤
• 프로토타입
• 웹 관련 스코프
  • request
  • session
  • application
  • websocket

spring docs(링크)에 기재된 스프링 스코프 설명

1. 싱글톤 스코프(Singleton Scope)

• (Default) 스프링 빈은 기본적으로 싱글톤 스코프로 생성
• 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 (스프링 컨테이너가 계속 관리)
• 싱글톤 스코프의 빈을 요청하면 스프링 컨테이너는 본인이 관리하는 스프링 빈 반환
• 같은 요청이 와도 항상 같은 인스턴스의 스프링 빈을 반환
• 싱글톤 빈은 스프링 컨테이너가 계속 관리하므로, 빈 초기화 시 초기화 메서드 호출, 빈 소멸 시 종료 메서드가 호출된다.

싱글톤은 Default여서 따로 설정을 안하지만, 설정을 하고 싶다면 빈 등록시 @Scope("singleton")을 불이면 된다.

@Scope("singleton")

2. 프로토타입 스코프(Prototype Scope)

• 스프링 컨테이너에 요청할 때마다 매번 새로운 빈을 생성해서 반환 (요청이 들어오면 그때 생성함)
• 스프링 컨테이너는 프로토타입 빈을 생성, 의존관계 주입, 초기화까지만 처리까지만 관여하고 그 이후는 관리 안한다. (요청마다 새로 빈을 생성하는 이유)
• 그래서 초기화 메서드는 호출되지만 종료 메서드는 호출되지 않는다.
• 스프링 컨테이너가 클라이언트에 빈을 반환하고나면 클라이언트가 빈의 모든 책임을 가진다.

 프로토타입 스코프 설정 - 빈 등록시 다음과 같은 애노테이션을 붙인다.

@Scope("prototype")

프로토타입 빈와 싱글톤 빈을 함께 사용시 문제점

싱글톤 빈이 프로토타입 빈에 대해 의존성을 갖고 있을 때 문제가 발생한다.

싱글톤 빈은 생성 시점에만 의존관계를 주입받기 때문에, 프로토타입 빈이 싱글톤 빈과 함께 계속 유지된다.

다시 말해 프로토타입 빈을 사용할 때마다 같은 프로토타입의 빈이 사용된다. 

하지만 이것은 매번 새로운 객체를 생성하는 프로토타입의 의도와는 맞지 않는다

이에 대한 해결책은 지정한 빈을 컨테이너에서 대신 찾아주는 DL 기능을 제공하는 ObjectProvider과 JSR-330 Provider이다.

직접 필요한 의존관계를 조회/탐색하는 것을 Dependency Lookup, 줄여서 DL이라고 부른다.

ObjectProvider<T>

스프링이 제공하는 DL 서비스. 참고로 과거에는 ObjectFactory가 있었는데, 여기에 편의 기능을 추가해서 ObjectProvider가 만들어졌다.

사용법

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;

public int logic() {
     PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
     ...
}

• ObjectProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. (DL)
• prototypeBeanProvider.getObject()를 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
• ObjectProvider는 빈으로 등록한 적이 없어도 스프링이 자동으로 만들어서 주입해준다.

특징

• 옵션, 스트림 처리등 편의 기능이 많다.
• 별도의 라이브러리가 필요 없다.
• 스프링에 의존적이다.

JSR-330 Provider<T>

마지막 방법은 javax.inject.Provider 라는 JSR-330 자바 표준을 사용하는 방법이다.

이 방법을 사용하려면 javax.inject:javax.inject:1 라이브러리를 gradle에 추가해야 한다.

사용법

@Autowired
private Provider<PrototypeBean> provider;

public int logic() {
     PrototypeBean prototypeBean = provider.get();
     ...
}

• provider의 get()을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. (DL)
• provider.get() 을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
• Provider는 빈으로 등록한 적이 없어도 스프링이 자동으로 만들어서 주입해준다.

특징

• 별도의 라이브러리가 필요하다.
• 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용할 수 있다.

3. 웹 관련 스코프

• 웹 관련 스코프는 웹 환경에서만 동작
• 싱글톤 스코프처럼 스프링 컨테이너가 생성 시점부터 종료시점까지 관리해준다.
• 따라서 초기화 메서드, 종료 메서드 모두 호출된다.

웬 관련 스코프 종류

1. request: HTTP 요청 하나가 들어오고 나갈 떄까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리
2. session: HTTP Session과 동일한 생명주기를 가지는 스코프
3. application: Servlet Context와 동일한 생명주기를 가지는 스코프
4. websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

모두 동작 방식은 비슷하므로 request 스코프에 대해서만 살펴보자.

requst 스코프

@Component
@Scope("request")
public class MyLogger {
}

로그를 출력하기 위한 MyLogger 클래스를 만들어보자. @Scope(value = "request") 를 사용해서 request 스코프로 지정했다. 이제 이 빈은 HTTP 요청 당 하나씩 생성되고, HTTP 요청이 끝나는 시점에 소멸된다.

컨트롤러와 서비스를 만들어 로그를 출력하기 위해 MyLogger 를 의존관계 주입받는다.

그리고 스프링 애플리케이션을 실행 시키면 오류가 발생한다. 그 이유는?

request 스코프 빈은 실제 HTTP 요청이 들어와야 생성된다. 하지만 애플리케이션 실행 시점에는 아직 요청이 들어오기 전이여서 myLogger가 생성되지 않았다. 그래서 빈을 생성할 수 없기 때문에 오류가 발생한 것이다.

해결방법 - 프록시 방식

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}

아까의 코드에 proxyMode = ScopedProxyMode.TARGET_CLASS 를 추가해주자.

• 적용 대상이 인터페이스가 아닌 클래스면, ScopedProxyMode.TARGET_CLASS 를 선택
• 적용 대상이 인터페이스면, ScopedProxyMode.INTERFACES 를 선택

@Scope 의 proxyMode = ScopedProxyMode.TARGET_CLASS) 를 설정하면, 스프링 컨테이너는 CGLIB 라는 바이트코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성한다.

따라서 애플리케이션 생성 시점에 HTTP 요청과 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다. (스프링 컨테이너에 가짜 프록시 객체 등록, 의존관계 주입도 가짜 프록시 객체가 주입된다.) 

클라이언트가 myLogger의 로직을 호출하면, 가짜 프록시 객체의 메서드가 호출된다.

그러나 가짜 프록시 객체는 내부에 진짜 myLogger를 찾는 방법을 알고있어서 가짜 프록시 객체가 진짜 myLogger.logic() 를 호출한다.

동작 정리

• CGLIB이라는 라이브러리로 내 클래스를 상속받은 가짜 프록시 객체를 만들어서 주입
• 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
• 가짜 프록시 객체는 실제 request scope와 관계 없다. 그냥 가짜 객체로 내부에 단순한 위임 로직만 있고 싱글톤처럼 동작한다.

특징 정리

• 프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.
• 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점이다.
• 단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.
• 가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있다. (다형성)

주의❗

프록시 방식를 통해 마치 싱글톤을 사용하는 것 같지만, 실제로는 다르게 동작하기 때문에 주의해서 사용해야 한다. 

이런 특별한 스코프는 꼭 필요한 곳에만 최소화해서 사용하자, 무분별하게 사용하면 유지보수하기 어려워진다.

이전 글 보러가기😉

2022.09.25 - [Spring] - 스프링 핵심 원리 - 기본편 | 7. 의존관계 자동 주입 1

1. 의존관계 자동 주입시 빈이 2개 이상 조회된다면?!

@Autowired는 타입(Type)으로 조회한다. 타입으로 조회 시 만약 빈이 2개 이상 일 때 어떤 문제가 발생할까?

바로 NoUniqueBeanDefinitionException 오류가 발생한다. 

이때 하위 타입으로 지정할 수도 있지만, 하위 타입으로 지정하는 것은 DIP를 위배하고 유연성이 떨어진다.

그리고 이름만 다르고, 완전히 똑같은 타입의 스프링 빈이 2개 있을 때는 해결이 안된다.

이럴 때, 의존관계 자동 주입에서 해결하는 방법은 3가지가 있다. 하나씩 살펴보자

• @Autowired 필드 명 매칭
• @Qualifier끼리 매칭 -> 못찾으면 빈 이름 매칭
• @Primary 사용

1. @Autowired 필드 명 매칭

1. @Autowired는 먼저 타입 매칭을 시도한다.
2. 이때 2개 이상의 빈이 있으면 필드 명, 파라미터 명으로 빈 이름 매칭한다. (1번이 실패했을 때 추가 동작)

2. @Qualifier 사용

• 빈 등록시 @Qualifier를 붙여준다.

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

• 의존관계 주입 시에 @Qualifier를 붙여주고 등록한 이름을 적어준다.
• 생성자 주입, setter 주입, 필드 주입 모두 사용 가능하다.

@Autowired
public OrderServiceImpl(@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
 	this.discountPolicy = discountPolicy;
}

만약 @Qualifier로 주입할 때, @Qualifier("mainDiscountPolicy")를 못찾으면 어떻게 될까?

그때는 mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾는다.

@Qualifier 정리

1. @Qualifier끼리 매칭
2. 1번 실패 시 빈 이름 매칭
3. 2번 실패 시 NoSuchBeanDefinitionException 예외 발생

3. @Primary 사용

@Primary는 우선순위는 정하는 방법이다. @Autowired 시에 여러 빈이 매칭되면 @Primary가 붙은 빈이 우선권을 가진다.

@Primary, @Qualifier 우선순위

스프링은 자동보다는 수동이, 넓은 범위의 선택권보다는 좁은 범위의 선택권이 우선순위가 높다.

따라서 @Qualifier가 우선순위가 높다.

@Primary, @Qualifier 활용

2개 이상의 빈을 사용해야 할 때, 코드에서 자주 사용하는 스프링 빈은 @Primary를 적용해서 기본값처럼 동작하게 한다. 덜 사용하는 스프링 빈은 @Qualifier를 지정해서 명시적으로 획득하는 방식을 사용한다.

2. 조회한 빈이 모두 필요할 때, List, Map

의도적으로 해당 타입의 스프링 빈이 모두 필요한 경우도 있다.

예를 들면 할인 서비스를 제공하는데, 클라이언트가 할인의 종류를 선택할 수 있다고 가정해보자.

@Component
class DiscountService {
    private final Map<String, DiscountPolicy> policyMap;
    private final List<DiscountPolicy> policies;
    
    @Autowired
    public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
        this.policyMap = policyMap;
        this.policies = policies;
    }
    
    public int discount(Member member, int price, String discountCode) {
        DiscountPolicy discountPolicy = policyMap.get(discountCode);
        
        return discountPolicy.discount(member, price);
    }
}

로직 분석

• DiscountService는 Map으로 모든 DiscountPolicy 타입의 빈들을 주입받는다.
• discount() 메서드는 discountCode로 스프링 빈 이름이 넘어오면 map에서 해당 이름을 가진 스프링 빈을 찾아서 실행한다.

주입 분석

• Map<String, DiscountPolicy>: map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DIscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
• List<DiscountPolicy>: DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
• 만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입한다.

참고. 위의 코드에서 생성자는 딱 1개이므로 @Autowired를 생략해서 의존관계가 자동 주입된다.

3. 자동, 수동의 올바른 실무 운영 기준

편리한 자동 기능을 기본으로 사용하자!

그렇다면 수동 등록할 때는 언제일까?

• 직접 기술 지원 객체를 등록할 때
  • 애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 설정 정보에 바로 보이게 하는 것이 유지보수 하기 좋다.
• 비지니스 로직 중에서 다형성을 적극 활용할 때
  • 위에서 조회한 빈이 모두 필요할 때, List, Map을 보면, DiscountService는 의존관계 자동 주입으로 DiscountPolicy 타입의 모든 빈을 주입받는다. 이런 경우 DiscountPolicy 의 구현 빈들만 따로 수동 등록하면, 설정 정보만 봐도 한 눈에 어떤 빈들이 주입될지 파악할 수 있다.

김영한님의 [스프링 핵심 원리 - 기본편]을 보고 작성한 글입니다:)

1. 다양한 의존관계 주입 방법

• 생성자 주입
• setter 주입
• 필드 주입
• 일반 메서드 주입

생성자 주입

• 생성자를 통해서 의존 관계를 주입 받는 방법
• 생성자 위에 @Autowired를 붙임
• 생성자 호출시점에 딱 1번만 호출되는 것이 보장
• 따라서 불변, 필수 의존관계에 사용

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

생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. (스프링 빈에만 해당)

setter 주입 (수정자 주입)

• setter 메서드를 통해서 의존관계를 주입하는 방법
• 선택, 변경 가능성이 있는 의존관계에 사용

@Autowired
public void setMemberRepository(MemberRepository memberRepository) {
	 this.memberRepository = memberRepository;
}

@Autowired의 기본 동작은 주입할 대상이 없으면 오류가 발생한다. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false)로 지정하면 된다.

필드 주입

• 이름 그대로 필드에 바로 주입하는 방법
• 외부에서 변경이 불가능해서 테스트하기 힘들다.
• DI 프레임워크가 없으면 아무것도 할 수 없다.
• 따라서 사용하지 않는 것이 좋다.

@Autowired
private MemberRepository memberRepository;

애플리케이션의 실제 코드와 관계 없는 테스트 코드

또는 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서 특별한 용도로 사용

일반 메서드 주입

• 일반 메서드는 통해서 입하는 방법
• 한 번에 여러 필드를 주입 받을 수 있다.
• 일반적으로 잘 사용하지 않는다.

@Autowired
public void init(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
     this.memberRepository = memberRepository;
	 this.discountPolicy = discountPolicy;
}

당연한 이야기지만 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다.

😆 결론은 생성자 주입을 사용하자!

최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다. 그 이유는 다음과 같다.

불변

• 대부분의 의존관계 주입은 애플리케이션 종료 전까지 변하면 안된다. 
• setter 주입을 사용하면, setter 메서드를 public으로 열어두어야 하고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다.
• 셍성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 불변하게 설계할 수 있다.

누락

• 생성자 주입을 사용하면 주입 데이터를 누락 했을 떄 컴파일 오류가 발생한다.
• 따라서 IDE에서 바로 어떤 값을 필수로 주입해야 하는지 알 수 있다.
• 생성자 주입을 사용하면 필드에 final키워드를 사용할 수 있다. 그래서 생성자에서 혹시라도 값이 설정되지 않은 오류를 컴파일 시점에 막아준다.

참고: 한 나머지 주입 방식은 모두 생성자 이후에 호출되므로, 필드에 final 키워드를 사용할 수 없다. 오직 생성자 주입 방식만 final 키워드를 사용할 수 있다.

정리

• 생성자 주입 방식은 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법이다.
• 항상 생성자주입을 선택하자! 가끔 필수 값이 아닌 경우에는 setter 주입 방식을 옵션으로 사용하면 된다.

2. 옵션 처리

@Autowired만 사용하면 required 옵션의 기본값이 true로 되어 있어서 자동 주입 대상이 없으면 오류가 발생한다.

따라서 주입할 스프링 빈이 없어도 동작해야 할 때, 자동 주입 대상을 옵션으로 처리하는 방법에 대해 소개하겠다.

1. @Autowired(required=false)

• 자동으로 주입할 대상이 없으면 setter 메서드 자체가 호출 안된다.

2. @Nullable

• 자동 주입할 대상이 없으면 null이 입력된다.

3. Optional<>

• : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다.

예제로 확인해보자.

스프링 빈이 아닌 Member를 의존관게 주입할 때, 위에 3가지 방법으로 옵션 처리를 해보자.

//결과: 호출 자체가 안됨
@Autowired(required = false)
public void setNoBean1(Member member) {
 	System.out.println("setNoBean1 = " + member);
}

//결과: null 호출
@Autowired
public void setNoBean2(@Nullable Member member) {
	 System.out.println("setNoBean2 = " + member);
}

//결과: Optional.empty 호출
@Autowired(required = false)
public void setNoBean3(Optional<Member> member) {
 	System.out.println("setNoBean3 = " + member);
}

출력 결과

setNoBean2 = null
setNoBean3 = Optional.empty

setNoBean1() 은 @Autowired(required=false)이므로 호출 자체가 안됐다.

참고: @Nullable, Optional은 스프링 전반에 걸쳐서 지원된다. 예를 들어서 생성자 자동 주입에서 특정 필드에만 사용해도 된다.

3. 롬복과 최신 트랜드

롬복 라이브러리가 제공하는 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다.

롬복 적용 전 코드

@Component
public class OrderServiceImpl implements OrderService {
     private final MemberRepository memberRepository;
     private final DiscountPolicy discountPolicy;
     
     //생성자가 1개이므로 @Autowired 생략
     public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
         this.memberRepository = memberRepository;
         this.discountPolicy = discountPolicy;
    }
}

롬복 적용 후 코드

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
     private final MemberRepository memberRepository;
     private final DiscountPolicy discountPolicy;
}

정리

최근에는 생성자를 딱 1개 두고 @Autowired를 생략하는 방법을 주로 사용한다. 여기에 Lombok 라이브러리의 @RequiredArgsConstructor을 함께 사용하면 기능은 다 제공하면서, 코드는 깔끔하게 사용할 수 있다.

+ Lombok이란?

• Annotation 기반으로 코드를 자동완성 해주는 자바 라이브러리
• 생성자, Getter, Setter, ToString 등의 반복되는 메소드를 작성
• 롬복을 사용했을 때의 장점
  • 어노테이션 기반의 코드 자동 생성을 통한 생산성 향샹
  • 반복코드 다이어트를 통해 가독성 및 유지보수성 향상
  • Getter / Setter 외 빌더 패턴이나 로그생성 등 다양한 방면으로 활용 가능

다음 글 보러 가기😉

2022.09.26 - [Spring] - 스프링 핵심 원리 - 기본편 | 7. 의존관계 자동 주입 2

김영한님의 [스프링 핵심 원리 - 기본편]을 보고 작성한 글입니다:)

지금까지의 수동 빈 등록

• 자바 코드의 @Bean이나 XML의 <bean> 등을 통해서 설정 정보에 직접 스프링 빈 등록한다.
• 등록해야 할 스프링 빈이 수백개가 되면, 설정 정보도 커지고 누락하는 문제가 발생한다.
• 무엇보다 개발자가 귀찮다...😭

그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공!

그럼 이제 컴포넌트 스캔이 무엇인지 알아봅시다.

1. 컴포넌트 스캔과 의존관계 자동 주입

컴포넌트 스캔 사용 방법 1

@Configuration
@ComponentScan
public class AutoAppConfig {
}

• 설정 정보에 @ComponentScan를 붙여주기만 하면 된다.
• 기존의 설정 정보과 달리 @Bean으로 등록한 클래스가 없다.
• 참고로 스프링 컨테이너는 @Configuration이 붙은 클래스를 설정 정보로 사용한다.

컴포넌트 스캔 사용 방법 2

@Component
public class MemoryMemberRepository implements MemberRepository { ... }

@Component
public class RateDiscountPolicy implements DiscountPolicy { ... }

• 컴포넌트 스캔은 이름 그대로 @Component가 붙은 클래스를 스캔해서 스프링 빈으로 등록한다.
• 따라서 스프링 빈으로 등록하고 싶은 클래스에 @Component를 붙인다.

컴포넌트 스캔 사용 방법 3 - 의존관계 자동 주입

@Component
public class MemberServiceImpl implements MemberService {
     private final MemberRepository memberRepository;
     
     @Autowired
     public MemberServiceImpl(MemberRepository memberRepository) {
     	this.memberRepository = memberRepository;
     }
}

• 수동 빈 등록에서는 @Bean으로 직접 설정 정보를 작성하고, 의존관계도 직접 명시했다.
• 이제는 이런 설정 정보 자체가 없으므로, @Autowired를 통해서 의존관계를 자동으로 주입해주어야 한다.

컴포넌트 스캔과 자동 의존관계주입 동작 방식

1. @ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다.
   • 빈 이름 기본 전략: 클래스명을 사용하되 맨 앞글자만 소문자 사용한다. ex) MemberServiceImpl 클래스 memberServiceImpl
   • 빈 이름 직접 지정: 만약 스프링 빈의 이름을 직접 지정하고 싶으면 @Component("memberService2") 이런 식으로 이름을 부여하면 된다.
2. 생성자에 @Autowired를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.
   • 기본 조회 전략: 타입이 같은 빈을 찾아서 주입한다.

2. 컴포넌트 스캔 탐색 위치와 기본 스캔 대상

탐색할 패키지의 시작 위치 지정

@ComponentScan(
 	basePackages = "hello.core",
}

• basePackages: 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다.
  • basePackages = {"hello.core", "hello.service"} 이렇게 여러 시작 위치를 지정할 수도 있다.
• basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다.
• 지정하지 않으면 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다.
• basePackages 지정은 생략하고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 방법을 권장한다. 

참고. 스프링 부트의 대표 시작 정보인 @SpringBootApplication를 프로젝트 시작 루트 위치에 두는 것이 관례이다. (그리고 @SpringBootApplication 안에 @ComponentScan이 들어있다)

컴포넌트 스캔 기본 대상

• @Component : 스프링 빈을 등록하기 위해 사용하는 가장 기본적인 애노테이션이다.

다음 애노테이션들은 모두 안에 @Component가 붙어있으며, @Component + 특별한 기능을 수행한다.

• @Controlller : 스프링 MVC 컨트롤러로 인식한다.
• @Service : 특별한 처리를 하지 않지만 개발자들이 핵심 비즈니스 로직이 있는 비즈니스 계층을 인식하는데 도움이 된다.
• @Repository : 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다.
• @Configuration : 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다.

3. 필터

• includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다.
• excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정한다.

FilterType 옵션

• ANNOTATION: 기본값, 애노테이션을 인식해서 동작한다.
• ASSIGNABLE_TYPE: 지정한 타입과 자식 타입을 인식해서 동작한다.
• ASPECTJ: AspectJ 패턴을 사용한다.
• REGEX: 정규 표현식을 사용한다.
• CUSTOM: TypeFilter 이라는 인터페이스를 구현해서 처리한다.

4. 중복 등록과 충돌

다음과 같은 상황에서 같은 빈 이름을 등록하면 어떻게 될까?

1. 자동 빈 등록 vs 자동 빈 등록
2. 수동 빈 등록 vs 자동 빈 등록

1. 자동 빈 등록 vs 자동 빈 등록

• 컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다.
  • ConflictingBeanDefinitionException 예외 발생

2. 수동 빈 등록 vs 자동 빈 등록

이런 경우 수동 빈 등록이 우선권을 가진다. (수동 빈이 자동 빈을 오버라이딩한다.)

해당 경우 남는 로그

Overriding bean definition for bean 'memoryMemberRepository' with a different definition: replacing

보통은 개발자가 이런 결과를 의도하기 보단 여러 설정들이 꼬여서 이런 결과가 만들어지는 경우가 대부분이다.

따라서 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생하도록 기본 값을 바꾸었다.

수동 빈 등록, 자동 빈 등록 오류시 스프링 부트 에러

Consider renaming one of the beans or enabling overriding by setting
spring.main.allow-bean-definition-overriding=true

김영한님의 [스프링 핵심 원리 - 기본편]을 보고 작성한 글입니다:)

1. 웹 애플리케이션과 싱글톤

웹 애플리케이션은 보통 여러 고객이 동시에 요청한다. 

• 스프링 없는 순수한 DI 컨테이너는 고객이 요청할 때마다 객체를 새로 생성한다.
• 메모리 낭비가 심하다.

해결방안은 해당 객체가 딱 1개만 생성되고, 공유하도록 설계하면 된다.

• 바로 싱글톤 패턴!!!

2. 싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다.

싱글톤 패턴을 적용한 예제 코드

public class SingletonService {
     //1. static 영역에 객체를 딱 1개만 생성해둔다.
     private static final SingletonService instance = new SingletonService();
     
     //2. public으로 열어서 객체 인스터스가 필요하면 이 static 메서드를 통해서만 조회하도록
    허용한다.
     public static SingletonService getInstance() {
     	return instance;
     }
     
     //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
     private SingletonService() {
     }
     
     public void logic() {
     	System.out.println("싱글톤 객체 로직 호출");
     }
}

• static으로 하면 자바가 실행될 때, static영역에 객체 instance를 하나 생성해서 올려둔다.
• 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다. 사용자는 생성하는 법은 모른다.
• 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.

💡 static이 붙은 정적 변수 설명보기

싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다.
• 내부 속성을 변경하거나 초기화 하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 결론적으로 유연성이 떨어진다.

3. 싱글톤 컨테이너

• 스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
• 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
• 스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

4. 싱글톤 방식의 주의점😱 (중요!)

• 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 떄문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다.
• 무상태(stateless)로 설계해야 한다.
  • 특정 클라이언트에 의존적인 필드가 있으면 안된다.
  • 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
  • 가급적 읽기만 가능해야 한다.
  • 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
• 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다.

상태를 유지할 경우 발생하는 문제점 예시

public class StatefulService {
     private int price; //상태를 유지하는 필드
     
     public void order(String name, int price) {
         System.out.println("name = " + name + " price = " + price);
         this.price = price; //여기가 문제!
     }
     
     public int getPrice() {
    	 return price;
     }
}

StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
StatefulService statefulService2 = ac.getBean("statefulService", StatefulService.class);

//ThreadA: A사용자 10000원 주문
statefulService1.order("userA", 10000);
//ThreadB: B사용자 20000원 주문
statefulService2.order("userB", 20000);

//ThreadA: 사용자A 주문 금액 조회
int price = statefulService1.getPrice();
//ThreadA: 사용자A는 10000원을 기대했지만, 기대와 다르게 20000원 출력
System.out.println("price = " + price);

• ThreadA가 사용자A 코드를 호출하고 ThreadB가 사용자B 코드를 호출한다 가정하자.
• StatefulService 의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다.
• 사용자A의 주문금액은 10000원이 되어야 하는데, 20000원이라는 결과가 나왔다.
• 진짜 공유필드는 조심해야 한다! 스프링 빈은 항상 무상태(stateless)로 설계하자.

5. @Configuration과 싱글톤

AppConfig를 살펴보면 memRepository()가 총 3번 호출되어 각각 다른 MemberRepository가 생성되면서 싱글톤이 깨지는 것처럼 보인다.

@Configuration
public class AppConfig {
     @Bean
     public MemberService memberService() {
     	return new MemberServiceImpl(memberRepository());
     }
     
     @Bean
     public OrderService orderService() {
     	return new OrderServiceImpl(memberRepository(), discountPolicy());
     }
     
     @Bean
     public MemberRepository memberRepository() {
    	 return new MemoryMemberRepository();
     }
     ...
}

▶ 스프링 빈에서 MemberRepository를 조회하는 테스트 코드를 작성해서 확인해보면 memberRepository 인스턴스는 모두 같은 인스턴스가 공유되어 사용된다.

6. @Configuration과 바이트코드 조작의 마법

스프링 컨테이너는 싱글톤 레지스트리다. 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다. 그런데 스프링이 자바 코드까지 어떻게 하기는 어렵다. 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.

▶비밀은 @Configuration에 있다!

@Test
void configurationDeep() {
     ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
     
     //AppConfig도 스프링 빈으로 등록된다.
     AppConfig bean = ac.getBean(AppConfig.class);

     System.out.println("bean = " + bean.getClass());
     //출력: bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70
}

• 실제 AnnotationConfigApplicationContext 에 파라미터로 넘긴 값은 스프링 빈으로 등록된다. 그래서 AppConfig도 스프링 빈이 된다.
• AppConfig 스프링 빈을 조회해서 클래스 정보를 출력해보면

// 순수한 클래스라면 다음과 같이 출력되어야 한다.
// bean = class hello.core.AppConfig

bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70

• 그런데 예상과는 다르게 클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 볼 수 있다.
• 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB이라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록한 것이다.
• 그 임의의 다른 클래스가 바로 싱글톤이 보장되도록 해준다. 아마도 다음과 같이 바이트 코드를 조작해서 작성되어 있을 것이다. 

AppConfig@CGLIB 예상 코드

@Bean
public MemberRepository memberRepository() {
 
     if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
     	return 스프링 컨테이너에서 찾아서 반환;
     } else { //스프링 컨테이너에 없으면
     	기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
     	return 반환
     }
}

• AppConfig@CGLIB이 memberRepository를 오버라이드한다.
• @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어진다.
• 덕분에 싱글톤이 보장된다.

참고 - AppConfig@CGLIB는 AppConfig의 자식 타입이므로, AppConfig 타입으로 조회 할 수 있다.

@Configuration 을 적용하지 않고, @Bean 만 적용하면 어떻게 될까?

@Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.

의존관계 주입이 필요해서 메서드를 직접 호출할 때 싱글톤을 보장하지도 않고, 그때 생성한 객체는 스프링 빈도 아니다.

결론: 스프링 설정 정보는 항상 @Configuration 을 사용하자!

1. 관심사의 분리

AppConfig 등장

• 애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스 AppConfig를 만든다.
• AppConfig는 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.
• AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.

설계 변경 후

• 객체의 생성과 연결은 AppConfig가 담당한다.
• AppConfig는 구체 클래스를 선택한다. ServiceImpl은 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다.
• ServiceImpl은 기능을 실행하는 책임만 지면 된다.
• 클라이언트인 ServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) 우리말로 의존관계 주입 또는 의존성 주입이라 한다.

사용, 구성의 분리

AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다.

할인 정책을 변경해도 AppConfig가 있는 구성 영역만 변경하면 된다.

사용 영역은 변경할 필요가 없고 클라이언트 코드인 주문 서비스 코드도 변경하지 않는다.

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

SRP 단일 책임 원칙

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

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

DIP 의존관계 역전 원칙

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

• 클라이언트 코드가 DiscountPolicy 추상화 인터페이스에만 의존하도록 코드를 변경
• 하지만 클라이언트 코드는 인터페이스만으로는 아무것도 실행할 수 없음
• AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입
• 이렇게해서 DIP 원칙을 따르면서 문제도 해결

OCP

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

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

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

제어의 역전 IoC(Inversion of Control)

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

의존관계 주입 DI(Dependency Injection)

• 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다.
• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
• 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

IoC 컨테이너, DI 컨테이너

• AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다.
• 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다. 

1. 비지니스 요구사항과 설계

회원

• 회원을 가입하고 조회할 수 있다.
• 회원은 일반과 VIP 두 가지 등급이 있다.
• 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)

주문과 할인 정책

• 회원은 상품을 주문할 수 있다.
• 회원 등급에 따라 할인 정책을 적용할 수 있다.
• 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.)
• 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수도 있다. (미확정)

2. 개발 

• 순수하게 자바 코드만 사용해서 개발
• 역할(인터페이스)과 구현(구현체)을 분리해서 자유롭게 구현 객체를 조립할 수 있게 설계했다. 덕분에 회원 저장소는 물론이고, 할인 정책도 유연하게 변경할 수 있다.

새로운 할인 정책 개발

• 유연한 설계가 가능하도록 객체지향 설계 원칙을 준수하며 개발했다.
• 기존의 할인 정책인 FixDiscountPolicy 대신 새로운 할인 정책 RateDiscountPolicy로 변경하면 된다.

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

문제점 발견

• 우리는 역할과 구현을 충실하게 분리했다. -> OK
• 다형성도 활용하고, 인터페이스와 구현 객체를 분리했다. -> OK
• OCP, DIP 같은 객체지향 설계 원칙을 충실히 준수했다 ->  NO
  • DIP 위반: 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다.
  • OCP 위반: 지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다!

의존관계

클라이언트인 OrderServiceImpl 이 DiscountPolicy 인터페이스 뿐만 아니라 FixDiscountPolicy 인 구체 클래스도 함께 의존하고 있다. 실제 코드를 보면 의존하고 있다! DIP 위반

정책 변경

FixDiscountPolicy 를 RateDiscountPolicy 로 변경하는 순간 OrderServiceImpl 의 소스 코드도 함께 변경해야 한다! OCP 위반

문제 해결

DIP를 위반하지 않도록 인터페이스에만 의존하도록 의존관계를 변경하면 된다.

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

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

❌ 또 다른 문제 발생! -> 구현체가 없어서 실행을 해보면 NPE(null pointer exception)가 발생한다.

해결방안

이 문제를 해결하려면 누군가가 구현 객체를 대신 생성하고 주입해주어야 한다.

그 누군가는 바로 스프링!!

다음 글 보러가기😋

2022.09.13 - [Spring] - 스프링 핵심 원리 - 기본편 | 스프링 핵심 원리 이해 정리2

1. 스프링이란?

스프링이라는 단어는 문맥에 따라 다르게 사용된다.

1. 스프링 DI 컨테이너 기술
2. 스프링 프레임워크
3. 스프링 부트 등을 모두 포함한 스프링 생태계

스프링 프레임워크

• 스프링의 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
• 웹 기술: 스프링 MVC, 스프링 WebFlux
• 데이터 접근 기술: 트랜잭션, JDBV, ORM지원, XML 지원

스프링 부트

• 스프링을 편리하게 사용할 수 있도록 지원
• 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성 - Tomcat 같은 웹 서버를 내장
• 손쉬운 빌드 구성을 위한 starter 종속성 제공
• 스프링과 3rd parth(외부) 라이브러리 자동 구성

2. 스프링의 핵심

• 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
• 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

3. 좋은 객체 지향 프로그래밍

객체 지향 프로그래밍

• 객체들의 모임으로 파악
• 각각의 객체는 메시지를 주고 받고, 데이터를 처리 (협력)
• 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게
• 객체 지향 특징 중 다형성을 활용

다형성 - 역할과 구현을 분리

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클래스, 즉 구현 객체
• 역할과 구현으로 구분하면 단순해지고, 유연해지며 변경도 편리
• 확장 가능한 설계
• 장점
  • 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
  • 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
  • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
  • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

다형성의 본질

• 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
• 다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야한다.
• 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

💡인터페이스를 안정적으로 잘 설계하는 것이 중요!!

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

• SRP: 단일 책임 원칙(Single Responsibility Principle)
• OCP: 개방-폐쇄 원칙 (Open/Closed Principle)
  • 소프트웨어 요소는 확장에는 열려 있으니 변경에는 닫혀 있어야 한다.
• LSP: 리스코프 치환 원칙 (Liskov Substitution Principle)
• ISP: 인터페이스 분리 원칙 (Interface Segregation Principle)
• DIP: 의존관계 역전 원칙 (Dependency Inversion Principle)
  • 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.”
  • 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻

정리❌

• 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
• 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
• 다형성 만으로는 OCP, DIP를 지킬 수 없다.

스프링 이야기에 왜 객체 지향 이야기가 나오는가?

• 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원
  • DI(Dependency Injection): 의존관계, 의존성 주입
  • DI 컨테이너 제공
• 클라이언트 코드의 변경 없이 기능 확장
• 쉽게 부품을 교체하듯이 개발

다음 글 보러가기😋

2022.09.13 - [Spring] - 스프링 핵심 원리 - 기본편 | 스프링 핵심 원리 이해 정리1