출처: 클린 소프트웨어
프록시 패턴의 구현목적은 Product의 Database접근과 Business logic의 분리를 위하여 사용하는 패턴입니다.
그렇다고 마구 사용해서는 안되는 패턴이며, 애플리케이션과 API(혹은 네트워크, 데이터베이스)의 둘중 혹은 하나가 잦은 변화가 생길때 중간 레이어에 프록시를 두어서 사용하길 권장드리는 패턴입니다.
위의 그림에서는 Product DB Proxy class가 user가 요청한 data를 Database에 읽거나 직접 쓰는 역할을하며, 그 가져온 data의 Business logic을 처리하는 부분은 Product Implementation 클래스를 delegate하여 사용하게 됩니다.
이렇게하면 장점은 Database에서 데이터를 가져오는 부분과 Business Logic부분을 따로 분리하여 관리할 수 있는 강점을 갖게 됩니다.
예제상황
상품에 대한정보도있으며, 이를 주문하는 시스템이 있다고 가정해 봅시다.
위의 그림에서는 상품에 대한 데이터베이스 정보와 비즈니스 로직을 처리하는 부분을 Product 인터페이스의 하위 클래스들로 구현된 클래스 다이어그램입니다.
또한, 주문을 처리하는 Order인터페이스가 있으며 Order에 대한 데이터베이스 정보와 비즈니스 로직을 처리하는 부분을 Order 인터페이스의 하위 클래스로 구현된 클래스 다이어그램입니다.
참고로 다이어그램에서 -Data로 끝나는 클래스 이름들은 Database에서 받아오는 객체의 정보입니다.
-Proxy로끝나는 하위 클래스들은 직접 Database에 접근 하는 클래스이며, -Impl로 끝나는 클래스들은 비즈니스 로직을 처리하는 부분이라고 보면 됩니다.
이 그림은 프록시들간의 관계를 나타내는 좀 더 응용된 프록시 패턴의 클래스 다이어그램으로 보시면 됩니다.
Product가 원래 존재하였는데, Order시스템 구현으로 인해서 OrderProxy에서 Order DB정보뿐만 아니라, Product의 데이터와 비즈니스 로직이 필요하여 ProductProxy를 OrderImpl에 주입하여주고, OrderImpl과 멤버필드인 item은 Product 인터페이스들을 통하여 Order와 관련된 비즈니스 로직을 처리할때 필요한 Product정보들을 받아오며 이용하는 것이 이 클래스 다이어그램의 가장 주목해서 보셔야 합니다.
프록시 요약
프록시는 사용이 간결함과 단순하지 않습니다. 프록시는 사용하기 까다롭습니다.
프록시의 이점
프록시는 매우 까다로운 특성이있습니다. 그럼에도 불구하고 매우 강력한 이점이 한가지 있는데 그것은 '관심의 분리' 입니다.
위의 클래스 다이어그램들을 살펴보시면 비즈니스로직과, 데이터베이스는 완전히 분리되어있습니다.
업무규칙과 데이터베이스 구현부의 분리가 아주 중요한 인스턴스에서는, 프록시가 적용하기 좋은 패턴이 될 수 있습니다.
애플리케이션은 보통 직접적으로 API를 물고 개발되는편입니다. 다만 서드파티의 API를 바로 사용하지않고 중간 레이어를 두어서 보다 추상적으로 사용하는 편이기도합니다.
단 어떤 경우에는 애플리케이션의 종속성으로 인해 레이어와 애플리케이션 관계가 뒤집어져야 하는 경우도 있습니다.
이런 종속성 뒤집기를 할때, 프록시 패턴이 적용될 수 있습니다. 애플리케이션은 프록시에 전혀 의존하지 않게 됩니다.
이렇게 애플리케이션과 API 사이의 관계정보는 오직 프록시에 집중되게 됩니다.
이 정보집중은 어찌보면 프록시가 악몽이 된다는 것을 의미합니다. API가 변경될때마다, 프록시도 변경됩니다. 애플리케이션이 변경될때마다 프록시도 변경됩니다. 프록시는 매우 다루기 어려운것이 되어버릴 수 있습니다.
차라리 자신의 악몽이 어디에 사는지 알고있는 편이 더 나을 수도 있습니다. 프록시가 없다면, 악몽은 애플리케이션 코드 전체에 퍼질수도 있기때문입니다.
단 프록시가 애플리케이션과 API의 철저한 분리가 이로울 때가 있는데, 스키마와 API 둘 모두 또는 어느 한쪽에서 잦은 변화가 발생하는 아주 큰 시스템의 경우는 거의 그렇습니다. 또 다른 많은 데이터베이스 엔진이나 미들웨어 엔진 위에 얹힐 수 있는 시스템도 그렇습니다. (왼쪽에서 2번째와 3번째 그림에 해당하는 말)
결론
대부분의 애플리케이션에는 프록시가 필요없습니다. 프록시는 아주 무거운 솔루션입니다.
하지만 우리는 프록시가 필요할 것이라는 것은 매우 매력적이라 생각합니다.
그런 필요가 실제로 생기기 한참전에 말입니다.
그러나 이것은 좋은 생각이 아닙니다. 특히 프록시에 대해서는 더욱 그렇습니다.
일단 퍼사드로 시작하고, 필요하면 리팩토링할 것을 권합니다. 그렇게하면 소중한 시간을 아끼고 문제를 줄일 수 있습니다.
유튜브 강의
참고했던 싸이트들
https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%ED%8C%A8%ED%84%B4#%EC%9E%90%EB%B0%94
'소프트웨어공학 > 디자인패턴 - JAVA' 카테고리의 다른 글
| 추상 팩토리 패턴 (Abstract factory pattern) (0) | 2020.05.09 |
|---|---|
| 전략 패턴 Strategy pattern (0) | 2017.06.10 |
| 어댑터 패턴 Adapter Pattern (0) | 2017.06.10 |
| 상태패턴 State Pattern (0) | 2017.06.10 |
| 팩토리 메소드 Factory method (0) | 2017.06.10 |