DI 의 끝을 모르겠다 ...
DI (Dependency Injection) 는 STRATEGY PATTERN(전략 패턴) 이다..
스프링 프레임워크의 모든 것의 중심엔 언제나 DI가 있다.
DI는 확장 포인트 임과 동시에 DI에 또 다른 패턴을 적용함으로써 동적으로 특정 행동을 추가할 수 도 있고,
변경할 수도 있다.
데코레이터 패턴을 잠깐 생각해보자..
InputStream is = new BufferedReaderInputStream(new FileInputStream());
이는 일종의 생성자를 이용한 DI라고 이해하면 된다. 생성자를 이용한 DI를 통해 특정 기능을 동적으로 추가해주고 있는 것이다.
프록시 를 살펴보자.
class HelloProxy{
Hello hello;
public void setHello(Hello hello){
this.hello = hello;
}
public void somework(){
// ..................do somework...
hello.somework();
}
}
아주 간단한 프록시를 작성해봤는데, 이 프록시 또한 역시 그 근간이 DI임을 한눈에 알아 볼 수 있다.
Hello 구현체라면 언제든 DI 주입 객체를 변경해서 행동을 변경할 수 있고(확장포인트),
Hello 구현체를 DI받아서 부가기능을 추가해주고 있다.
스프링의 중심엔 항상 DI가 있고, 스프링의 수많은 확장포인트 또한 DI 가 있기에 가능한 것이다.
스프링 3.2 의 @ENABLE*류 나 configurer 패턴 역시 DI가 근간을 이루고 있다.
-내용추가
토비의 스프링 3.1 VOL2 740p 中 -
"DI 는 AOP의 동작원리이기도 하다. 굳이 AOP라는 수준 높은 단계까지 가지 않더라도, 간단히 데코레이터 패턴이나 프록시 패턴을 적용할 수 있다."
나의 이런 깨달음을 증명이라도 하듯, 토비의 스프링에 위와 같은 내용이 기재되어 있다.
여담. 이 글의 카테고리를 스프링으로 해야할지 , 디자인패턴으로 해야할지 모르겠다..