Creational Patterns ( 생성 패턴 )
These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case.
생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다.
Structural Patterns ( 구조적 패턴 )
These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
구조적 패턴들은 클래스와 객체의 구성에 관여한다.
Behavioral Patterns ( 행위적 패턴 )
These design patterns are specifically concerned with communication between objects.
이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.
오늘 살펴볼 Facade 패턴은 Structural 패턴에 속한다. 이 패턴은 컴포지트 패턴과 비슷한 다이어그램을 가지고 있다.
Facade는 퍼사드라고 읽는다. 퍼케이드, 패케이드 이딴식으로 읽는게 아니다.
Facade Pattern Structure
패턴의 목적 ( Intent ) :
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
퍼사드 패턴은 서브시스템 내부에 있는 클래스에 접근할 수 있는 하나의 통합된 인터페이스를 제공하는 패턴이다.
패턴이 나오게 된 동기 ( Motivation ) :
큰 시스템을 작은 시스템으로 나누는 것은 시스템의 복잡도를 낮춰준다. 그리고 디자인의 공통 목표는 서브시스템들 사이의 의존성을 줄이고 커뮤니케이션 횟수를 줄이는 것인데 퍼사드 패턴이 이를 위한 방법중 하나이다. 아래 그림에서 커다란 사각형이 서브시스템이고 그 안에 작은 사각형들은 서브시스템의 클래스들을 의미한다. 그리고 서브시스템 밖에는 클라이언트가 서브시스템에 접근할 때 사용되는 클래스들이 있다.
그런데 왼쪽 그림을 보면 서브시스템에 접근하기 위해서 클라이언트 클래스가 직접적으로 서브시스템 내부의 클래스를 호출하는 방식이다. 그림으로봐도 뭔가 복잡해 보인다. 서브시스템이 변경되면?? 클라이언트 쪽에서도 수정해야하는 부분이 생길 것이고 큰 프로젝트였다면 어디를 수정해야 할지 찾아내기도 힘들것이다. 그래서 이를 퍼사드 패턴을 적용해서 바꾸면 오른쪽과 같은 그림이 나온다. 클라이언트 클래스들이 퍼사드를 통해서 서브시스템에 접근하도록 한 것이다. 이때 꼭 퍼사드를 통해서만 서브시스템에 접근할 수 있어야 한다는 것은 아니다. 단지 퍼사드를 통해서 서브시스템에 접근할 수 있도록 길을 열고 그렇게 유도만 하는 것이다. 강제성이 없다는 뜻이다.
이 패턴을 사용하는 대표적인 예가 컴파일러이다. 컴파일러는 아래와 같이 구현된다.
유용성 ( Applicability ) :
Use the Facade pattern when
· you want to provide a simple interface to a complex subsystem.
Subsystems often get more complex as they evolve. Most patterns, when
applied, result in more and smaller classes. This makes the subsystem
more reusable and easier to customize, but it also becomes harder to use
for clients that don't need to customize it. A facade can provide a
simple default view of the subsystem that is good enough for most
clients. Only clients needing more customizability will need to look
beyond the facade.
복잡한 서브시스템에 접근할 수 있는 간단한 인터페이스를 제공하고 싶을 때 사용
· there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.
서브시스템을 클라이언트 또는 다른 서브시스템으로부터 디커플시킴으로써 독립성과 휴대성(이식성)을 높이기 위해서 사용
· you want to layer your subsystems.
Use a facade to define an entry point to each subsystem level. If
subsystems are dependent, then you can simplify the dependencies between
them by making them communicate with each other solely through their
facades.
등장 인물 ( Participants ) :
원리 ( Collaborations ) :
· Clients communicate with the subsystem by sending requests to Facade, which forwards them to the appropriate subsystem object(s). Although the subsystem objects perform the actual work, the facade may have to do work of its own to translate its interface to subsystem interfaces.
클라이언트는 퍼사드에 요청을 함으로써 복잡한 서브시스템에 접근한다.
· Clients that use the facade don't have to access its subsystem objects directly.
클라이언트는 복잡한 서브시스템의 객체에 직접적으로 접근할 필요가 없다.
패턴 사용의 장단점 ( Consequences ):
The Facade pattern offers the following benefits:
1. It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use. 사용자가 알아야 하는 서브시스템의 범위를 줄여준다.
2. It promotes weak coupling between the subsystem and its clients. 1번의 이유로 사용자와 서브시스템 사이의 커플링 관계를 약화시켜준다. Often
the components in a subsystem are strongly coupled. Weak coupling lets
you vary the components of the subsystem without affecting its clients.
Facades help layer a system and the dependencies between objects. They
can eliminate complex or circular dependencies. This can be an important
consequence when the client and the subsystem are implemented
independently. Reducing compilation dependencies is vital in large
software systems. You want to save time by minimizing recompilation when
subsystem classes change. Reducing compilation dependencies with
facades can limit the recompilation needed for a small change in an
important subsystem. A facade can also simplify porting systems to other
platforms, because it's less likely that building one subsystem
requires building all others.
3. It doesn't prevent applications from using subsystem classes if they need to. 사용자가 원할 때에는 서브시스템에 직접 접근하여 내부 클래스를 사용할 수 있다.Thus you can choose between ease of use and generality.
관련 패턴들 :
Abstract Factory can
be used with Facade to provide an interface for creating subsystem
objects in a subsystem-independent way. Abstract Factory can also be
used as an alternative to Facade to hide platform-specific classes.
Mediator is
similar to Facade in that it abstracts functionality of existing
classes. However, Mediator's purpose is to abstract arbitrary
communication between colleague objects, often centralizing
functionality that doesn't belong in any one of them. A mediator's
colleagues are aware of and communicate with the mediator instead of
communicating with each other directly. In contrast, a facade merely
abstracts the interface to subsystem objects to make them easier to use;
it doesn't define new functionality, and subsystem classes don't know
about it.
Usually only one Facade object is required. Thus Facade objects are often Singletons.
추가 정보 :
어댑터 패턴과 퍼사드 패턴의 차이점은 얼마나 많은 클래스를 wrap하느냐가 아니다. Adapter 패턴은 하나 이상의 클래스를 묶어서 클라이언트가 원하는 출력이 나오도록 하는 것이고 Facade 패턴은 클라이언트가 사용하기에는 복잡한 인터페이스를 하나로 묶고 간단한 접근경로를 제공함으로써 클라이언트가 손쉽게 복잡한 인터페이스 내부의 기능을 활용할 수 있도록 하는 것이다.
출처 : http://sourcemaking.com/design_patterns/facade
Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )
http://www.journaldev.com/1557/facade-pattern-in-java-example-tutorial
[디자인패턴] 커맨드 패턴 ( Command Pattern ) (0) | 2015.11.03 |
---|---|
[디자인패턴] 컴포지트 패턴 ( Composite Pattern ) (0) | 2015.11.03 |
[디자인패턴] 브리지 패턴 ( Bridge Pattern ) (0) | 2015.11.03 |
[디자인패턴] 프록시 패턴 ( Proxy Pattern ) (0) | 2015.11.03 |
[디자인패턴] 데코레이터 패턴 ( Decorator Pattern ) (0) | 2015.11.03 |