▼ 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)
▼ Why ? 흔히 "SOLID" 라고 불리는 객체지향 5원칙은 이상적인 객체지향 설계를 하려 한다면 반드시 알아야 하는 소프트웨어 개발 원칙이다. 전에 공부했던 '싱글톤 패턴' 이나 '프록시 패턴' 과 같
ukym-tistory.tistory.com
프록시 패턴의 단점
- 코드의 복잡도가 증가하여 가독성이 떨어질 수 있다.
- 객체를 생성할 때 프록시 객체를 하나 더 생성해주는 과정으로 인해, 객체 생성이 다발적으로 요구되는 경우엔 성능이 저하될 수 있다.
( 객체를 생성할 때 스레드 생성과 동기화도 필요한 경우라면 성능이 더욱 저하될 수 있다. )
▼ 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)
▼ Why ? 흔히 "SOLID" 라고 불리는 객체지향 5원칙은 이상적인 객체지향 설계를 하려 한다면 반드시 알아야 하는 소프트웨어 개발 원칙이다. 전에 공부했던 '싱글톤 패턴' 이나 '프록시 패턴' 과 같
ukym-tistory.tistory.com
프록시 패턴의 단점
- 코드의 복잡도가 증가하여 가독성이 떨어질 수 있다.
- 객체를 생성할 때 프록시 객체를 하나 더 생성해주는 과정으로 인해, 객체 생성이 다발적으로 요구되는 경우엔 성능이 저하될 수 있다.
( 객체를 생성할 때 스레드 생성과 동기화도 필요한 경우라면 성능이 더욱 저하될 수 있다. )
