Facade Pattern
💡 The facade pattern is a software-design pattern commonly used in object-oriented programming. Analogous to a facade in architecture, a facade is an object that serves as a front-facing interface masking more complex underlying or structural code. - wikipedia퍼사드 패턴은 객체 지향 프로그래밍에서 자주 사용되는 소프트웨어 디자인 패턴이에요. 건축에서의 facade(건물의 정면)와 유사하게, facade(퍼사드)는 내부적으로 혹은 구조적으로 더 복잡한 코드를 가려주는 상위 수준의 인터페이스의 역할을 하는 객체라고 하네요.
저는 디자인 패턴을 공부할 때는, 반드시 “이 디자인 패턴은 어떤 문제를 해결하기 위해 등장했을까?” 라는 의문을 던져야 한다고 생각해요. 이 고민 없이 단순히 코드와 도식만 본다면, 시간이 지나 잘 기억나지도 않을 뿐더러 해당 디자인 패턴에 맞춰 구현된 코드를 봐도 눈에 잘 들어오지도 않더라고요. 그러면 이 퍼사드 패턴은 어떤 문제를 해결하기 위해 등장하게 되었을까요?
첫번째로, 퍼사드 패턴은 시스템의 복잡성을 줄이고 사용성을 높이기 위해서 등장했어요. 어떻게 복잡성을 줄이고 사용성을 높였는지 이해하기 위해서는 아래 그림을 보는게 좋을 것 같아요. 퍼사드 디자인 패턴은 하나의 시스템을 서브 시스템들의 조합으로 구성하고 있는데요.
- Client : 클라이언트는 서브 시스템을 알지 못해요. 단지 Facade를 호출할 뿐이죠.
- Facade : 퍼사드는 클라이언트의 요청에 맞는 서브 시스템이 무엇인지 알고 있어요. 그래서 클라이언트의 요청을 적절한 서브 시스템에 전달하죠.
- Subsystem : 서브 시스템들은 또 각자의 기능을 수행할 뿐, 서로서로 알지 못해요. 또 Facade 객체에 대해서도 알지 못 하고 오직 facade에 의해서 사용될 뿐이죠.
이렇게 여러 서브 시스템이 복잡하게 얽히면서 구현한 로직을, facade와 서브 시스템으로 분리하게 되면 복잡성을 확연히 줄일 수 있게 돼요. 그리고 클라이언트 입장에서는 훨씬 시스템을 사용하기가 쉬워지죠. 그리고 퍼사드를 사용함으로써 기존에 없던 facade-subsystem 간의 계층도 생기게 되었어요.
또 퍼사드 패턴을 적용하면 서브 시스템 클래스에서 변화가 생겨도 클라이언트 코드에 영향이 가지 않기 때문에 종속성을 낮출 수가 있게 돼요. 즉 퍼사드 패턴의 핵심은 클래스 간 상호작용의 복합도를 낮추는 데 있다고 말할 수 있는거죠!
Facade vs Adapter
(비교정리 : Coming soon)
Facade vs Front Controller
퍼사드 패턴의 핵심은 내부 시스템의 복잡도를 감추고 상호작용할 더 단순한 메소드를 제공하는 것이에요. 다시 말해, 퍼사드는 클라이언트의 요청을 듣고 서브 시스템을 적절히 이용하여 요청을 들어주는 이외의 로직을 담고 있어선 안 되는 거죠.
반면, 컨트롤러는 컨트롤러 자체가 자신만의 로직을 가질 수가 있어요. Servlet에서 오는 요청을 바로 처리할 수도 있고, 서비스 단으로 이어주는 요청을 처리할 수도 있죠. 프론트 컨트롤러 패턴은 퍼사드 패턴처럼 앞 단에서 클라이언트의 요청을 받아들인다는 점에서 구조적으로 비슷해 보일 수는 있어요. 하지만 그 등장 목적은 내부 시스템의 복잡도를 감추기 위함이 아니에요. 모든 요청을 먼저 받는 컨트롤러를 둠으로써 모든 요청에 공통적으로 처리해야하는 로직을 효과적으로 처리하는데 있죠.
그럼, 다음 시간에는 본격적으로 Logging에 대해 알아보도록 할게요!
Reference
