[Spring][UMC 8주차 mission] @RestControllerAdvice의 장점, 의존성 주입(DI) 개념

@RestControllerAdvice란?

@ReponseBody는 HttpMessageConverter를 통해서 응답 값을 자동으로 json으로 직렬화 한 뒤 응답해주는 역할을 한다.

즉, @RestControllerAdvice 란,
@ResponseBody + @ControllerAdvice 가 합쳐진 어노테이션이다.

응답 형식이 json으로 되는 것은 @ControllerAdvice가 아니다. 응답 형식을 json으로 통일해야 하는 입장에서는 @ResponseBody 어노테이션을 붙혀주어야 한다.
(저번 프로젝트에서 Multipart/form-data 형식으로 받아오는 api인데 @RequestBody @RequestParam ... <요놈들 멋대로 썼다가 이틀 밤샜던 적이 있다.)

비슷한 @ControllerAdvice 녀석과 밑의 구현체를 통해 차이점을 비교해보자.

@Target(ElementType.TYPE) 
@Retention(RetentionPolicy.RUNTIME) 
@Documented 
@ControllerAdvice 
@ResponseBody 
public @interface RestControllerAdvice {
    ~~
} 

@Target(ElementType.TYPE) 
@Retention(RetentionPolicy.RUNTIME) 
@Documented 
@Component 
public @interface ControllerAdvice {
    ~~
}

@ControllerAdvice는 컨트롤러에 대해 @ExceptionHandler, @InitBinder, @ModelAttribute가 적용된 메소드에 AOP(관점 지향 프로그래밍)를 적용하기 위해 디자인되었다.

또한, @Component가 포함되어 있기 때문에, 스프링 프로젝트 내에서 빈으로 관리된다.

의존성 주입(DI, Dependency Injection)

---

어떤 객체가 사용하는 의존 객체를 직접 만들지 않고, 주입(injection)받아 사용하는 것입니다.

예를 들어, 위의 사례에서 배터리 일체형 장난감은 배터리가 떨어지면 장난감을 새로 구입해야한다.
이때, 장난감은 배터리에 의존(dependency)하고 있다고 볼 수 있다.
따라서 배터리 일체형 장난감의 코드는 다음과 같다:

public class Toy {
	private Battery battery;
    
    public Toy() { // 생성자에서 배터리 객체 생성
    	battery = new Battery(); 
    }
}

해당 코드를 보면 배터리가 떨어지면, 배터리 교체가 불가능하므로 new 생성자를 통해 새로운 장난감을 생성해야 한다.
즉, 유연성이 굉장히 떨어진다는 것을 알 수 있겠다.

반면, 배터리 분리형의 장난감의 경우에는 어떨까?

public class Toy {

	private Battery battery;

	public Toy(Battery battery) {
		this.battery = battery;
	}

	public void setBattery(Battery battery) {
		this.battery = battery;
	}
}

생성자, 혹은 setter을 통해 배터리를 주입할 수 있다.
배터리가 다 떨어지더라도, 장난감을 새로 마련할 필요 없이 배터리만 교체하면 되므로 유연성이 보장된다.

즉, 스프링은 의존성 주입(Dependency Injection)을 통해 모듈 간의 결합도가 낮아지고 유연성이 높아질 수 있다.