[토비의 스프링] 다이내믹 프록시와 팩토리 빈

 

1) 프록시와 프록시 패턴, 데코레이터 패턴

- 트랜잭션 경계설정 코드를 비즈니스 로직 코드에서 분리해낼 때

  적용했던 기법을 다시 검토해보자. 

  단순히 확장성을 고려해서 한 가지 기능을 분리한다면  전형적인 전략 패턴을 사용하면 된다.

  

- 트랜잭션 기능에는 추상화 작업을 통해 이미 전략 패턴이 적용되어 있다.

  하지만 전략 패턴으로는 트랜잭션 기능의 구현 내용을 분리해냈을 뿐이다.

  트랜잭션을 적용한다는 사실은 코드에 그대로 남아 있다. 

 

- 트랜잭션이라는 기능은 사용자 관리 비즈니스 로직과는 성격이 다르기 때문에

  아예 그 적용 사실 자체를 밖으로 분리할 수 있다. 

  아래 그림과 같이 부가기능 전부를 핵심 코드가 담긴 클래스에서 독립시킬 수 있다. 

 

- 이렇게 분리된 부가기능을 담은 클래스는 중요한 특징이 있다.

  부가기능 외의 나머지 모든 기능은 원래 핵심기능을 가진 클래스로 위임해줘야 한다.

  핵심기능은 부가기능을 가진 클래스의 존재 자체를 모른다.  

  따라서 부가기능이 핵심기능을 사용하는 구조가 되는 것이다. 

 

- 문제는 이렇게 구성했더라도 클라이언트가 핵심기능을 가진 클래스를 직접 사용해버리면

  부가기능이 적용될 기회가 없다는 점이다.

  그래서 부가기능은 마치 자신이 핵심기능을 가진 클래스인 것처럼 꾸며서,

  클라이언트가 자신을 거쳐서 핵심기능을 사용하도록 만들어야 한다. 

 

- 그러기 위해서는 클라이언트는 인터페이스를 통해서만 핵심기능을 사용하게 하고,

  부가기능 자신도 같은 인터페이스를 구현한 뒤에 

  자신이 그 사이에 끼어들어야 한다. 

 

- 그러면 클라이언트는 인터페이스만 보고 사용을 하기 때문에

  자신은 핵심기능을 가진 클래스를 사용할 것이라고 기대하지만,

  사실은 아래 그림처럼 부가기능을 통해 핵심기능을 이용하게 되는 것이다.

 

- 부가기능 코드에서는 핵심기능으로 요청을 위임해주는 과정에서

  자신이 가진 부가적인 기능을 적용해줄 수 있다.

  비즈니스 로직 코드에 트랜잭션 기능을 부여해주는 것이 바로 그런 대표적인 경우다. 

 

- 이렇게 마치 자신이 클라이언트가 사용하려고 하는 실제 대상인 것처럼 위장해서

  클라이언트의 요청을 받아주는 것을 대리자, 대리인과 같은 역할을 한다고 해서 프록시(proxy)라고 부른다.

  그리고 프록시를 통해 최종적으로 요청을 위임받아 처리하는 실제 오브젝트를 타깃(target) 또는 실체(real object)라고 부른다.

  아래 그림은 클라이언트가 프록시를 통해 타깃을 사용하는 구조를 보여주고 있다. 

  

- 프록시의 특징은 타깃과 인터페이스를 구현했다는 것과

  프록시가 타깃을 제어할 수 있는 위치에 있다는 것이다. 

  

- 프록시는 사용 목적에 따라 두 가지로 구분할 수 있다.

  첫째는 클라이언트가 타깃에 접근하는 방법을 제어하기 위해서다.

  두 번째는 타깃에 부가적인 기능을 부여해주기 위해서다.

  두 가지 모두 대리 오브젝트라는 개념의 프록시를 두고 사용한다는 점은 동일하지만,

  목적에 따라서 디자인 패턴에서는 다른 패턴으로 구분한다.