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 ) :

· Facade (Compiler)
o knows which subsystem classes are responsible for a request.
o delegates client requests to appropriate subsystem objects.
· subsystem classes (Scanner, Parser, ProgramNode, etc.)
o implement subsystem functionality.
o handle work assigned by the Facade object.
o have no knowledge of the facade; that is, they keep no references to it.

원리 ( 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.

추가 정보 :  

• Facade defines a new interface, whereas Adapter uses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one.
• Whereas Flyweight shows how to make lots of little objects, Facade shows how to make a single object represent an entire subsystem.
• Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communications between colleague objects. It routinely "adds value", and it is known/referenced by the colleague objects. In contrast, Facade defines a simpler interface to a subsystem, it doesn't add new functionality, and it is not known by the subsystem classes.
• Abstract Factory can be used as an alternative to Facade to hide platform-specific classes.
• Facade objects are often Singletons because only one Facade object is required.
• Adapter and Facade are both wrappers; but they are different kinds of wrappers. The intent of Facade is to produce a simpler interface, and the intent of Adapter is to design to an existing interface. While Facade routinely wraps multiple objects and Adapter wraps a single object; Facade could front-end a single complex object and Adapter could wrap several legacy objects.
• Facade pattern is more like a helper for client applications, it doesn’t hide subsystem interfaces from the client. Whether to use Facade or not is completely dependent on client code.
• Facade pattern can be applied at any point of development, usually when the number of interfaces grow and system gets complex.
• Subsystem interfaces are not aware of Facade and they shouldn’t have any reference of the Facade interface.
• Facade pattern should be applied for similar kind of interfaces, its purpose is to provide a single interface rather than multiple interfaces that does the similar kind of jobs.
• We can use Factory Pattern with Facade to provide better interface to client systems.

어댑터 패턴과 퍼사드 패턴의 차이점은 얼마나 많은 클래스를 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