퍼사드 패턴(Facade Pattern)
서브시스템에 있는 인터페이스들에 대한 통합된 인터페이스를 제공하는 디자인 패턴이다.
Facade: 클라이언트의 요청을 적절한 서브시스템 클래스에 위임한다.
Subsystem classes: 서브시스템 기능을 구현한다. 서브시스템 클래스는 facade에 의해서만 사용된다.
Client: Facade에게 특정 행동을 수행해달라고 요청한다.
온라인 쇼핑몰에서의 주문 시스템을 예로 들어보자.
서브시스템을 사용하기 쉽게 하는 인터페이스(퍼사드)를 두어 간편하게 주문을 넣을 수 있도록 변경하였다.
퍼사드 패턴을 적용한 결과 서브시스템 클래스에서 변화가 생겨도 클라이언트 코드에 영향이 가지 않는다.
퍼사드 패턴의 핵심은 상호작용 결합도를 낮추는데 있다. 따라서 위와 같이 세 개의 서비스가 하나의 트랜잭션 안에서 처리되어 연속적으로 일어나는 경우도 퍼사드 패턴이고, 아래처럼 독립적으로 각각을 사용하는 것도 퍼사드 패턴이다.
장점
1. 간소화된 인터페이스 제공: 클라이언트에게 단순한 인터페이스를 제공하므써 클라이언트는 내부 동작을 몰라도 편리하게 사용할 수 있다.
2. 시스템 구조 감추기: 퍼사드는 내부 시스템의 복잡성을 감춘다. 클라이언트는 퍼사드만 알면 되며, 내부 구조나 시스템의 변경 사항에 대해 알 필요가 없다.
3. 결합도 감소: 시스템의 각 구성 요소 간의 결합도를 낮출 수 있다. 각 하위 시스템이 독립적으로 변경될 수 있으며, 이는 시스템의 유지 보수와 확장을 용이하게 한다.
4. 재사용성 향상: 퍼사드는 여러 클라이언트에서 동일한 인터페이스를 사용할 수 있게 해준다. 이로써 코드의 재사용성이 높아진다.
단점
1. 유연성 제한: 퍼사드는 내부 시스템에 대한 간단한 접근을 제공하지만, 퍼사드 패턴에 구현되지 않은 특정 기능에 접근하기 어려울 수 있다. 이런 경우에는 직접적으로 하위 시스템과 상호 작용 하거나 퍼사드 패턴에 추가해주어야 한다.
2.추가적인 추상화: 퍼사드 패턴을 도입하면 또 다른 추상화 레이어가 추가되므로, 적절하게 구현하지 않는다면 성능 손실이 발생할 수 있다.
3. 순환 종속성 가능성: 하위 시스템이 퍼사드를 참조하고 퍼사드가 다시 하위 시스템을 참조하는 경우에는 순환 종속성이 발생할 수 있다.
많은 기능을 구현하면 안되는 이유
1. 단일 책임 원칙 위배: 퍼사드는 하위 시스템과의 인터페이스 역할을 해야 한다. 많은 기능을 추가하면 퍼사드가 여러 가지 역할을 수행하게 되어 단일 책임 원칙을 위배하게 된다.
2. 복잡성 증가: 퍼사드가 많은 기능을 갖게 되면, 퍼사드 자체의 복잡성이 증가한다. 이는 퍼사드의 관리와 유지보수를 어렵게 만들 수 있다.
3. 결합도 증가: 퍼사드가 많은 기능을 제공할 경우, 퍼사드가 다른 여러 하위 시스템에 의존하게 된다.
4. 테스트 어려움: 많은 기능을 포함한 퍼사드는 모든 기능을 테스트 하기에 복잡하고 많은 시간이 걸릴 수 있다.
5. 재사용 어려움
'CS' 카테고리의 다른 글
| [JPA] 영속성 컨텍스트 및 이점(5가지) (0) | 2023.10.27 |
|---|---|
| [Design Pattern] 가교 패턴(브릿지 패턴, Bridge Pattern) (0) | 2023.10.26 |
| [Design Pattern] 전략 패턴(Strategy Pattern) (0) | 2023.10.23 |
| [Design Pattern] 팩토리 메서드(Factory method pattern) (1) | 2023.10.23 |
| [Spring] Bean의 생명주기 및 Scope (0) | 2023.10.20 |