ㅇㄹㄴㅇ

HelloController가 직접 SimpleHelloService를 의존하고 있는 상태

그렇다는 얘기는 helloController는 SimpleHelloService를 직접 의존하고 있고

의존 관계 방향은 다음과 같

 

DI를 얘기하면서 이런식으로 설계를 바꿨다.

의존관계의 방향이 바뀐것을 알 수 있다.

이렇게 하면 장점이

HelloController 코드에 손을 대지 않고

HelloService interface를 구현한 클래스를 교체해가면서 다양하게 적용하는것이 가능하다.

 

이런 작업을 가능하게 해주는 것이 DI이고

DI라는 것은 HelloController는 구현체에 의존하지 않지만

Runtime시에는 HelloController가 구현체를 사용하고 있으니까 object level에서는 의존하는 것으로 볼 수 있다.

 

의존관계는 spring container가 뜰 때 spring container가 DI의 Assembler 역할을 해서

두 개를 엮어주는 역할을 한다. (의존 관계 주입)

 

 

HelloDecorator : 다른 클래스와 마찬가지로 HelloService를 구현한 구현체이자, HelloService type의 어떠한 오브젝트를 의존하고 있다. (HelloController처럼)

HelloDecorator가 HelloService가 구현한 또다른 object를 호출할 수 있다는 것이다.

 

이렇게 하는 이유는 DI를 이용하여 Runtime시에 아래와 같은 구조를 만들 수 있기 때문이다.

 

SimpleHelloService는 main 로직이 존재하고

실제 기능을 담당하는 SimpleHelloService를 건드리지 않은 채로

기능과 책임을 추가하고 싶다면 helloDecorator를 중간에 삽입함으로써 가능하다.

HelloController가 HelloDecorator를 의존하고 HelloDecorator가 SimpleHelloService를 의존하도록

 

 

지금은 HelloController가 SimpleHelloService를 의존하는 구조이다.

사실은 명시적으로 HelloController가 SimpleHelloService를 사용해라고 지정하지는 않고,

HelloController 는 HelloService 인터페이스를 의존하고 있다.

 

HelloService 인터페이스를 구현한 구현체가 SimpleHelloService 만 존재하기 때문에 

Spring Container가 알아서 단일 주입 후보를 찾아서 사용하도록 한다.

이런 방식을 Autowiring이라고 한다.

 

Decorator는 여러가지 기능과 책임을 부가적으로 주는 구현을 만들면 Decorator라고 부를 수 있다.

 

 

실체 대신 뭔가 대신하는 것을 가져다 놓는다

HelloController가 보기에는 HelloService가 구현한 로직을 담아놓은 Object로 보지만

실제로는 이것을 대리해서

여러가지 부가적인 효과를 제공해주는 것이다.

 

대표적으로 뒤에 실제 로직을 가지고 있는 오브젝트가 크고 비싼것일 때

구지 서버가 시작될 때 미리 만들어 둘 필요가 없고

정말 어쩌다가 필요로 하는 시점에

첫번째 요청이 들어오면 on demand로 object로 만들면 된다.

최대한 지연시켜서 가져오면 될 때 사용하면 되고

 

실제로 구현해보지는 않을 예정이다.