프록시 패턴 정리

구조/7주차-프록시/summary/프록시 패턴.md

@@ -0,0 +1,43 @@
+# 프록시 패턴
+
+> 특정 객체에 대한 접근을 제어하거나 기능을 추가 할 수 있는 패턴
+
+![](https://refactoring.guru/images/patterns/diagrams/proxy/structure-indexed.png)
+
+**Service Interface**: 서비스를 구현해야하는 인터페이스
+
+**Service**:  비즈니스 로직을 제공하는 서비스 클래스
+
+**Proxy**: 서비스 객체를 받아서 참조하는 필드를 가지는 클래스. 
+
+**프록시**는 서비스 객체에 요청을 전달하기전에 느린 초기화, 로깅, 엑세스 제어, 캐싱등을 완료한 후에 값을 전달 할 수 있다.
+
+## 프록시는 언제 사용되는가?
+
+- 원래 하려던 기능을 수행하고, 부가 작업(로깅, 인증, 네트워크 통신)을 하고 싶을때
+
+- 비용이 큰 연산들(DB Query, 큰 파일 텍스트)을 실제로 필요한 시점에 수행시키고 싶을때
+
+## 프록시 패턴 예제 코드
+
+## 패턴의 장/단점
+
+✅ 장점:
+
+- 클라이언트 모르게 서비스 객체를 제어할 수 있다.
+- 클라이언트가 서비스객체의 생명주기를 관리에 대해서 신경쓰지 않아도 된다. 
+- 프록시는 서비스객체가 없거나, 존재하지 않더라도 작동할 수 있다.
+- OCP(개방/폐쇄 원칙) 클라이언트 혹은 서비스 변경없이 새로운 프록시들을 추가 가능하다.
+
+🚨 단점:
+
+- 많은 양의 클래스를 필요로 할때마다 코드가 점점 복잡해진다.
+- 서비스의 대한 응답이 딜레이 될 수 있다.
+
+## 비슷한 패턴
+
+- **어뎁터**는 Wrapped 객체를 다른 인터페이스를 제공하지만, **프록시**는 같은 인터페이스로 제공하고, **데코레이터**는 확장 인터페이스를 제공한다. 
+
+- **파사드**는 복잡한 엔티티를 버퍼하고, 자체적인 초기화한다는 점이 **프록시**랑 되게 비슷한데. 이런 파사다와 달리 프록시는 서비스 객체와 동일 인터페이스를 가지고 있으므로, 교환이 가능해진다.
+
+- **데코레이터**와 **프록시** 역시 비슷한 구조를 가지고 있지만, 매우 다른 의도를 가지고 있다. 두 패턴들은 모두 한 객체가 다른 객체에 작업의 일부를 위임하도록 되어 있는 구성으로 기반으로 하고 있다. **프록시**는 서비스 객체의 수명 주기를 스스로 관리하지만, 데코레이터는 이런 생명주기를 client에 의해 제어한다.