[Software Design Pattern] 프록시 패턴 (Proxy Pattern)

▼ Why ? What ?

GDSC - Web 커리큘럼에서 빈(Bean)을 등록하는 과정에서 빈(Bean)을 수동으로 등록하는 것과 자동으로 등록하는 것의 차이를 잘 모르는 것 같아 다시 공부를 했다. 빈을 수동으로 등록할 때 스프링은 'CGLIB' 라는 라이브러리를 통해 해당 빈(Bean)에 "프록시 패턴(Proxy Pattern)" 을 적용한다고 한다. 이를 통해 "프록시 패턴" 이라는 소프트웨어 디자인 패턴에 대해 처음 알게 되었다. "프록시 패턴" 은 빈을 수동 등록하는 과정을 이해하기 위해서만이 아니라 백엔드에서도 중요한 개념인 것 같아 따로 더 알아보았고, 기억이 나지 않을 때마다 찾아보기 위해 공부한 내용을  정리해두려고 한다.

---

▼ 프록시 패턴 (Proxy Pattern)

 

프록시 패턴 ?

 

• "프록시(Proxy)" 는 "대리인" 이라는 뜻으로, 무언가를 대신 처리하는 의미이다.
  ➜ 이러한 개념을 그대로 객체에 적용시켜보면,
  어떤 객체를 사용하기 위해 그 객체를 직접 참조하는 것이 아니라, 해당 객체를 대행할 수 있는 객체를 통해 접근하는 방식을 떠올려볼 수 있다.
  ➜ 따라서, 해당 객체가 메모리에 존재하지 않더라도 기본적인 정보를 참조하거나 설정할 수 있게 되고, 실제 객체의 기능이 반드시 필요한 시점까지 객체의 생성을 미룰 수 있게 된다 !
  ➜ 이 점이 바로 "프록시 패턴" 의 중요한 특징이고, 프록시(Proxy)는 "인터페이스 역할을 하는 클래스" 라고 생각해도 좋을 것 같다.

---

 

프록시 패턴을 사용하는 이유 ?

 

• 앞서 말한 프록시 패턴의 장점들을 객체지향 5원칙에 따라 생각해보면 사용하지 않을 이유가 없다.
  
  
  • SRP : 실제 객체와 클라이언트 사이에서 대리인 역할을 해주기 때문에, 객체들은 자신의 주요 기능에만 집중할 수 있게 된다.
  • OCP : 클라이언트 코드를 수정하지 않고도 실제 객체의 동작을 변경하거나 확장할 수 있다.
  • LSP : 프록시 객체가 실제 객체를 대행할 수 있으며, 즉 클라이언트가 실제 객체 대신 프록시 객체를 사용해도 동일한 동작을 수행할 수 있다.
  • ISP : 프록시 패턴은 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공할 수 있다.
  • DIP : 프록시 패턴으로 인해 클라이언트(고차원 모듈)가 인터페이스(저차원 모듈)에 의존하긴 하지만, 클라이언트가 실제 객체에 직접 의존하지 않을 수 있고 모두 추상화(인터페이스)에 의존하게 된다.
    

 

SOLID 원칙 (참고 자료) - [Software Design Pattern] 객체지향 5원칙 (SOLID) — Uykm_Note (tistory.com)

[Software Design Pattern] 객체지향 5원칙 (SOLID)

---

 

프록시 패턴의 단점

 

• 코드의 복잡도가 증가하여 가독성이 떨어질 수 있다.
  
  
• 객체를 생성할 때 프록시 객체를 하나 더 생성해주는 과정으로 인해, 객체 생성이 다발적으로 요구되는 경우엔 성능이 저하될 수 있다.
  ( 객체를 생성할 때 스레드 생성과 동기화도 필요한 경우라면 성능이 더욱 저하될 수 있다. )