Bridge pattern

1. Design Pattern
Bridge Pattern
A Structural design pattern
Copyright © Astha

2. The Problem
Suppose a task has been given of writing a program that will draw rectangles
with either of two drawing programs. It also have been told that when
instantiate a rectangle, it will know whether it should use drawing program 1
(DP1) or drawing program 2 (DP2).
The rectangles are defined as two pairs of points, as represented in the
following figure. The differences between the drawing programs are
summarized
in Table below.
X2, Y2
X1, Y1
Copyright © Astha

3. The Problem
DP1 DP2
Used to draw a draw_a_line( x1, drawline( x1, x2,
line y1, x2, y2) y1, y2)
Used to draw a draw_a_circle( x, y, drawcircle( x, y, r)
circle r)
we don’t want the code that draws the rectangles to worry about what
type of drawing program it should use. It occurs to me that because the
rectangles are told what drawing program to use when instantiated, I can
have two different kinds of rectangle objects: one that uses DP1 and one
that uses DP2. Each would have a draw method but would implement it
differently.
Copyright © Astha

4. The Problem
Copyright © Astha

5. The Problem
A straightforward approach: implementing two shapes and two
drawing programs.
Copyright © Astha

6. The Problem
Bridge in Action
Copyright © Astha

7. Intent
Decouple an abstraction from its implementation so that the two can vary
independently.
Copyright © Astha

8. Applicability
Use the Bridge pattern when
 you want to avoid a permanent binding between an abstraction and its
implementation. This might be the
case, for example, when the implementation must be selected or switched at
run-time.
 both the abstractions and their implementations should be extensible by
subclassing. In this case, the Bridge
pattern lets you combine the different abstractions and implementations and
extend them independently.
 changes in the implementation of an abstraction should have no impact on
clients; that is, their code should
not have to be recompiled.
Copyright © Astha

9. Structure
Copyright © Astha

10. 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.
Copyright © Astha

11. Collaborations
• Abstraction forwards client requests to its Implementor object.
Copyright © Astha

12. Consequences
 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.
 Improved extensibility. You can extend the Abstraction and Implementor
hierarchies independently.
 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).
Copyright © Astha

13. Implementation
1. Only one Implementor. In situations where there's only one implementation,
creating an abstract Implementor class isn't necessary. This is a degenerate
case of the Bridge pattern; there's a one-to-one relationship between
Abstraction and Implementor. Nevertheless, this separation is still useful
when a change in the implementation of a class must not affect its existing
clients—that is, they shouldn't have to be recompiled, just relinked.
2. Creating the right Implementor object. How, when, and where do you decide
which Implementor class to instantiate when there's more than one?
Copyright © Astha

14. Assignment
A document viewer has been made for an enterprise solution (desktop
application), which supports viewing of some specific types of documents. The
supporting types are HTML, Microsoft Word and Microsoft Excel.
Underneath, the document viewer uses an abstract interface of the document
which contains methods to show the document in the viewer.
Now the enterprise application is going to have a web solution where there
would be another document viewer (different in several aspects from the
existing one) with the same functionalities as it is now in the desktop version.
Use the Bridge pattern to solve the problem in such a way that new document
types can be easily incorporated into the system and new type of document
viewer can also be incorporated.
Copyright © Astha