※ 프록시 패턴(OCP : Open & Close principle)
- 특정한 객체에 접근하기 전에 프록시 객체를 지나서 접근하는 패턴
- 클라이언트가 원래 사용하려고 했던 클래스를 직접 쓰지 않고,
중간에 프록시(대리인)를 거쳐서 사용하게 된다.(비서를 거쳐야 사장을 만날 수 있다.)
- 초기화 지연, 접근 제어, 로깅, 캐싱 등 다양하게 응용해 사용할 수 있다.
※ 프록시의 특징
인터페이스 타입으로 필드를 하나 가지고 있다(데코레이터 패턴처럼 참조를 하고 있다)
본인의 인터페이스 타입(레퍼런스)을 참조하고 있다.(프록시에서 RealSubject를 참조하기 위함)
프록시로 들어온 오퍼레이션 중에 RealSubject를 사용해야하면 그걸 사용하고,
그 전이나 후에 어떤 추가 적인 작업을 할 수 있게끔 프록시에서 RealSubject를 참조할 필드가 하나 필요함.
이러한 기능을 만들면 기존 코드를 유지한 체 필요한 기능을 손쉽게 추가할 수 있다(OCP)
※ 기존의 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계가 되어야 함.
→ SOILD(객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙) 중 OCP, 개방 폐쇄의 원칙
- 기본적인 일은 DefaultGameService에서 하고 있고,
부가적인 일은 Proxy에서 하고 있다
- 기존에 코드는 전혀 변경되지 않으면서, 프록시를 거쳐서 기능 구현사용 예시
기존 코드를 전혀 건드리지 않고, 프록시를 사용하려고 하면 기존에 있던 서비스를 상속쓸 수 밖에 없겠지만
가급적이면 인터페이스로 gameService를 다시 설계를 하는 것이 좋다.
기존 서비스는 DefaultGameService를 만들고 GameService(interface)를 implements해서 RealSubject에 해당하는 구현체로 만들어서 사용하는 것이 더 좋다(유연함)
그 다음에 GameSErviceProxy(프록시)를 만들어서 GameService(interface)를 implements 하고 마치 데코레이터 패턴처럼 필드를 하나 가지고 있고, 이 타입으로 타겟에 해당하는 것을 주입 받아서 사용
클라이언트는 이와 같이 GameServiceProxy(프록시)를 거쳐서 DefaultGameService객체를 사용하게 되는 것
→ 이렇게 설정을 하게 되면 DefaultGameService는 본인이 하는 일 그대로 하고 있는 것이고 부가적인 일은 Proxy에서 하게 되는 것이다.
※ 장점
- 기존 코드를 변경하지 않고 새로운 기능을 추가할 수 있다.
- 기존 코드가 해야 하는 일만 유지할 수 있다.
- 기능 추가 및 초기화 지연 등으로 다양하게 활용할 수 있다.
※ 단점
- 코드의 복잡도가 증가한다.
