프록시 패턴 (Proxy Pattern)

• 제어 흐름을 조정하기 위한 목적으로 중간에 대리자를 두는 패턴

---

구조

• Subject (주체): 프록시와 실제 서비스 객체가 공통적으로 구현해야 하는 인터페이스를 정의
• RealSubject (실제 주체): 주요 서비스를 제공하는 실제 객체(원본 대상 객체)
• Proxy (프록시): 실제 주체를 대신하여 클라이언트 요청을 처리하는 객체
  클라이언트와 실제 주체 사이에서 중간 역할을 수행

---

사용시기

• 원격 프록시 (Remote Proxy): 원격 서비스에 접근할 때 사용, 클라이언트는 로컬 프록시 객체를 통해 원격 객체에 접근

• 가상 프록시 (Virtual Proxy): 실제로 생성하기에 비용이 많이 드는 객체에 대한 접근을 제어하기 위해 사용, 실제 객체의 생성과 초기화를 지연시키고, 필요한 시점에 생성

• 보호 프록시 (Protection Proxy): 특정 사용자가 특정 객체에 접근할 권한이 있는지 확인하는 경우 사용

---

장단점

장점

• 보안 강화: 보호 프록시를 사용하여 객체에 대한 접근을 제어, 보안 검사를 수행

• 성능 개선: 가상 프록시를 사용하여 객체의 생성을 지연시키고 필요한 시점에 생성하여 성능 향상

• 코드 재사용: 프록시를 사용하여 추가적인 기능을 쉽게 추가하거나 변경 가능

단점

• 복잡성 증가: 프록시 객체를 추가함으로써 코드의 복잡성이 증가

• 추가 비용: 프록시를 사용하는 데에는 일부 추가적인 비용이 발생

• 네트워크 오버헤드: 원격 프록시 사용 시 네트워크를 통해 객체에 접근하고 결과를 받아오는 과정에서 네트워크 오버헤드가 발생할 수 있음

  • 프록시가 원격 서버에 있는 실제 객체에 접근할 때, 데이터를 전송하고 받는 데 걸리는 시간과 이 과정에서 발생하는 지연과 데이터 전송 비용 등

---

파사드 패턴 (Facade Pattern)

• 복잡한 시스템에 대하여 단순한 인터페이스를 제공하여 하위 시스템 집합에 대한 간소화된 인터페이스를 제공하는 패턴

---

구조

• 파사드 (Facade): 클라이언트가 상호작용하는 단일 인터페이스 제공, 하위 시스템의 복잡성을 숨기고, 적절한 하위 시스템에 요청을 전달
• 서브 시스템 (Subsystem): 파사드가 접근하는 복잡한 시스템이나 라이브러리

---

사용 시기

• 복잡한 시스템이나 라이브러리를 단순화할 필요가 있을 때
• 다른 시스템과의 상호작용이 필요하고, 이를 단순하게 처리하고자 할 때
• 클라이언트 코드를 단순화하고, 내부 구조에 대한 의존성을 줄이고자 할 때
• 시스템 변경에 대비하여 유연성을 확보하고자 할 때

---

장단점

장점

• 간단한 인터페이스 제공: 복잡한 시스템을 단순화시켜 클라이언트가 쉽게 사용할 수 있는 인터페이스를 제공
  시스템 구조 이해 용이: 시스템의 내부 구조를 숨기므로, 사용자가 시스템을 이해하고 파악 용이
• 결합도 낮춤: 클라이언트와 서브시스템 간의 결합도를 낮추어 유지보수 및 확장성 향상
• 유연한 확장성: 새로운 기능을 추가하거나 기존 기능을 변경할 때 파사드를 수정하면 되므로 유연한 확장성을 제공

단점

• 일부 기능 제한: 모든 기능을 파사드에 포함할 수 없으므로, 일부 기능은 직접적인 접근이 필요할 수 있음
• 추가 비용: 새로운 기능을 추가할 때 파사드를 수정해야 하므로 일부 추가 비용이 발생
• 오버헤드: 클라이언트가 시스템에 접근하는 경우, 모든 요청은 파사드를 통해 이루어지므로 성능이 저하 될 수 있음.(추가적인 오버헤드 발생)

---

비교

객체 지향 소프트웨어 개발에서 코드의 유연성, 재사용성 및 유지보수성을 향상시키는 데 사용

패턴	목적	범위
프록시 패턴	접근 제어, 보조 기능 추가	단일 객체
파사드 패턴	복잡한 시스템을 단순화	하위 시스템 전체 대상