Bridge pattern

14
Design Pattern Design Pattern Bridge Pattern A Structural design pattern Copyright © Astha

description

Bridge pattern

Transcript of Bridge pattern

Page 1: Bridge pattern

Design PatternDesign PatternBridge PatternA Structural design pattern

Copyright © Astha

Page 2: Bridge pattern

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

Page 3: Bridge pattern

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.

Page 4: Bridge pattern

The ProblemThe Problem

Copyright © Astha

Page 5: Bridge pattern

The ProblemThe Problem

Copyright © Astha

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

Page 6: Bridge pattern

The ProblemThe Problem

Copyright © Astha

Bridge in Action

Page 7: Bridge pattern

IntentIntent

Copyright © Astha

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

Page 8: Bridge pattern

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.

Page 9: Bridge pattern

StructureStructure

Copyright © Astha

Page 10: Bridge pattern

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.

Page 11: Bridge pattern

CollaborationsCollaborations

Copyright © Astha

• Abstraction forwards client requests to its Implementor object.

Page 12: Bridge pattern

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

Page 13: Bridge pattern

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?

Page 14: Bridge pattern

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.