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.
이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.
오늘 살펴볼 Bridge 패턴은 Structural 패턴에 속한다.
말그대로 A와 B를 연결하는 다리역할을 하는 패턴이다.
Bridge Pattern Structure
패턴의 목적 ( Intent ) :
Decouple an abstraction from its implementation so that the two can vary independently.
브리지 패턴은 어댑터 패턴과 비슷하다고 생각할 수 있다. 하지만 그 목적이 분명히 다름을 숙지해야한다. 브리지 패턴은 추상화를 함으로써 두개를 구분짓기 위해서 사용하는 패턴이다.
패턴이 나오게 된 동기 ( Motivation ) :
When
an abstraction can have one of several possible implementations, the
usual way to accommodate them is to use inheritance. An abstract class
defines the interface to the abstraction, and concrete subclasses
implement it in different ways. But this approach isn't always flexible
enough. Inheritance binds an implementation to the abstraction
permanently, which makes it difficult to modify, extend, and reuse
abstractions and implementations independently.
Consider the
implementation of a portable Window abstraction in a user interface
toolkit. This abstraction should enable us to write applications that
work on both the X Window System and IBM's Presentation Manager (PM),
for example. Using inheritance, we could define an abstract class Window
and subclasses XWindow and PMWindow that implement the Window interface
for the different platforms. But this approach has two drawbacks:
1. It's inconvenient to extend the Window abstraction to cover different kinds
of windows or new platforms. Imagine an IconWindow subclass of Window that
specializes the Window abstraction for icons. To support IconWindows for
both platforms, we have to implement two new classes, XIconWindow and
PMIconWindow. Worse, we'll have to define two classes for every kind of
window. Supporting a third platform requires yet another new Window subclass
for every kind of window.
2. It makes client code platform-dependent. Whenever a client creates a window, it instantiates a concrete class that has a specific implementation. For example, creating an XWindow object binds the Window abstraction to the X Window implementation, which makes the client code dependent on the X Window implementation. This, in turn, makes it harder to port the client code to other platforms.
Clients should be able to create a window without
committing to a concrete implementation. Only the window implementation
should depend on the platform on which the application runs. Therefore
client code should instantiate windows without mentioning specific
platforms.
The Bridge pattern addresses these problems by putting the Window abstraction and its implementation in separate class hierarchies. There is one class hierarchy for window interfaces (Window, IconWindow, TransientWindow) and a separate hierarchy for platform-specific window implementations, with WindowImp as its root. The XWindowImp subclass, for example, provides an implementation based on the X Window System.
유용성 ( Applicability ) :
Use the Bridge pattern when
등장 인물 ( Participants ) :
· Abstraction (Window)
o defines the abstraction's interface.
o maintains a reference to an object of type Implementor.
· RefinedAbstraction (IconWindow)
o Extends the interface defined by Abstraction.
· Implementor (WindowImp)
o
defines the interface for implementation classes. This interface
doesn't have to correspond exactly to Abstraction's interface; in fact
the two interfaces can be quite different. Typically the
Implementor
interface provides only primitive operations, and Abstraction defines
higher-level operations based on these primitives.
· ConcreteImplementor (XWindowImp, PMWindowImp)
o implements the Implementor interface and defines its concrete implementation.
All operations on Window subclasses are implemented in terms of abstract operations from the WindowImp interface. This decouples the window abstractions from the various platform-specific implementations. We refer to the relationship between Window and WindowImp as a bridge, because it bridges the abstraction and its implementation, letting them vary independently.
원리 ( Collaborations ) :
패턴 사용의 장단점 ( Consequences ):
The Bridge pattern has the following consequences:
1. Decoupling interface and implementation.
An implementation is not bound permanently to an interface. The
implementation of an abstraction can be configured at run-time. It's
even possible for an object to change its implementation at run-time.
Decoupling
Abstraction and Implementor also eliminates compile-time dependencies
on the implementation. Changing an implementation class doesn't require
recompiling the Abstraction class and its clients. This property is
essential when you must ensure binary compatibility between different
versions of a class library.
Furthermore, this decoupling encourages
layering that can lead to a better-structured system. The high-level
part of a system only has to know about Abstraction and Implementor.
2. Improved extensibility. You can extend the Abstraction and Implementor hierarchies independently.
3. Hiding implementation details from clients.
You can shield clients from implementation details, like the sharing of
implementor objects and the accompanying reference count mechanism (if
any).
관련 패턴들 :
An Abstract Factory can create and configure a particular Bridge.
The Adapter pattern is geared toward making unrelated classes work together. It is usually applied to systems after they're designed. Bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently.
추가 정보 :
출처 : http://sourcemaking.com/design_patterns/bridge
Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )
[디자인패턴] 컴포지트 패턴 ( Composite Pattern ) (0) | 2015.11.03 |
---|---|
[디자인패턴] 퍼사드 패턴 ( Facade Pattern ) (0) | 2015.11.03 |
[디자인패턴] 프록시 패턴 ( Proxy Pattern ) (0) | 2015.11.03 |
[디자인패턴] 데코레이터 패턴 ( Decorator Pattern ) (0) | 2015.11.03 |
[디자인패턴] 어댑터 패턴 ( Adapter Pattern ) (0) | 2015.11.03 |