0% found this document useful (0 votes)
28 views10 pages

Bridge Using Electrical

The Bridge pattern decouples an abstraction from its implementation so that they can vary independently. It does this by putting the abstraction and implementation hierarchies in separate class hierarchies connected via a bridge relationship. This allows subclasses to extend the abstraction and implementation hierarchies independently, improving extensibility. It also hides implementation details from clients, improving flexibility to change implementations without impacting clients.

Uploaded by

Kunal Tiwary
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views10 pages

Bridge Using Electrical

The Bridge pattern decouples an abstraction from its implementation so that they can vary independently. It does this by putting the abstraction and implementation hierarchies in separate class hierarchies connected via a bridge relationship. This allows subclasses to extend the abstraction and implementation hierarchies independently, improving extensibility. It also hides implementation details from clients, improving flexibility to change implementations without impacting clients.

Uploaded by

Kunal Tiwary
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 10

Structural Bridge (151)

Bridge
Object Diagram for
Bridge using Electrical
Switch Example

The Bridge pattern decouples an abstraction from its


implementation, so that the two can vary independently. A
household switch controlling lights, ceiling fans, etc. is an
example of the Bridge. The purpose of the switch is to turn a
device on or off. The actual switch can be implemented as a pull
chain, a simple two position switch, or a variety of dimmer
switches
Structural Bridge (151)

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

Also Known As
Handle/Body

Problem
"Hardening of the software arteries" has occurred by using
subclassing of an abstract base class to provide alternative
implementations. This locks in compile-time binding between
interface and implementation. The abstraction and
implementation cannot be independently extended or composed.
Structural Bridge (151)

Illustration: Problem
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 x
window system and IBM’s PM .

Using inheritance, its possible to define abstract class


Window and subclasses Xwindows and PM that
implement the Window interface for the different
platforms. But this has 2 drawbacks.
Structural Bridge (151)

Illustration: Problem
Draw Backs:
1> It’s inconvenient to extend the Window
abstraction to cover different kinds of windows or
new platform ( ie. Every new platform a new
Window subclass for every Kind of Window is
necessary )
2> It makes client code platform-dependent.
Whenever a client creates a window, it instantiates a
concrete class that has specific implementation. This,
in turn, makes it harder to port the client code to
other platforms.
Structural Bridge (151)

Illustration:
Solution

Bridge patterns address 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 separate hierarchy for
platform-specific window implementations, with WindowImp as its
root.
All operation on Window subclasses are implemented in terms of
abstract operations from the WindowImp interface. This decouples
the Window abstractions form the various platfom-specific
implementations. We refer to the relationship between window and
WindowImp as a Bridge.
Structural Bridge (151)
Solution:
Decompose the component's interface and implementation into orthogonal
class hierarchies.
The interface class contains a pointer to the abstract implementation class.
This pointer is initialized with an instance of a concrete implementation
class, but all subsequent interaction from the interface class to the
implementation class is limited to the abstraction maintained in the
implementation base class.

The client interacts with the interface class, and it in turn "delegates" all
requests to the implementation class.

The interface object is the "handle" known and used by the client; while the
implementation object, or "body", is safely encapsulated to ensure that it
may continue to evolve, or be entirely replaced (or shared at run-time
Structural Bridge (151)
Applicability
• Use the Bridge pattern when:
 you want run-time binding of the implementation and want to
avoid permanent binding between an abstract and its
implementation.
 Both the abstraction and their implementations should be
extensible by subclassing.
 Change in the implementation of an abstraction should have
no impact on client; ie their code should not be recomplied
 you want to share an implementation among multiple objects,
 you have a proliferation of classes resulting from a coupled
interface and numerous implementations
 you need to map orthogonal class hierarchies.
Structural Bridge (151)

Structure

Collaborations
Abstraction forwards client request to its
implementers object.
Structural Bridge (151)

Consequences include:
 decoupling the object's interface & implementation

 improved extensibility (you can extend (i.e. subclass)


the abstraction and implementation hierarchies
independently),

 hiding details from clients. Clients are hidden form the


implementation details, like sharing of implementers
objects and the accompanying reference count(in c++)
mechanism(if any)
Structural Bridge (151)
Model:

You might also like