bridge pattern

Design PatternDesign PatternBridge PatternA Structural design pattern

Copyright © Astha

The ProblemThe Problem

Copyright © Astha

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 summarizedin Table below.

X1, Y1

X2, Y2

The ProblemThe Problem

Copyright © Astha

DP1 DP2

Used to draw aline

draw_a_line( x1, y1, x2, y2)

drawline( x1, x2, y1, y2)

Used to draw acircle

draw_a_circle( x, y, r)

drawcircle( x, y, 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.

The ProblemThe Problem

Copyright © Astha

The ProblemThe Problem

Copyright © Astha

A straightforward approach: implementing two shapes and two drawing programs.

The ProblemThe Problem

Copyright © Astha

Bridge in Action

IntentIntent

Copyright © Astha

Decouple an abstraction from its implementation so that the two can vary independently.

ApplicabilityApplicability

Copyright © Astha

Use the Bridge pattern when you want to avoid a permanent binding between an abstraction and its implementation. This might be thecase, 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 Bridgepattern 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 shouldnot have to be recompiled.

StructureStructure

Copyright © Astha

ParticipantsParticipants

Copyright © Astha

• 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.

CollaborationsCollaborations

Copyright © Astha

• Abstraction forwards client requests to its Implementor object.

ConsequencesConsequences 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

ImplementationImplementation

Copyright © Astha

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?

AssignmentAssignment

Copyright © Astha

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.