The Bridge Design Pattern

Aamir Siddiqui

University of Scranton

SE 516 – Dr Bi

 

Intent

Decouple an abstraction from its implementation so that the two can vary independently. A Bridge pattern is a design time Design Pattern.

In 30 Seconds

The catch here is "decouple abstraction from implementation". 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, simple two-position switch, or a variety of dimmer switches.

Problem

"Hardening of the software arteries" has occurred by using sub classing 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.

 

How? Where? And When? to create the correct Implementor.

USE

Use the Bridge pattern when:

Consequences include:

 

Structure

 

 

 

 

 

 

Structure of Bridge

 

 

 

 

 

 

Classification

There is one of three classifications that all design patterns fall into:

 

  1. Creational
  2. Structural and
  3. Behavioral. 

 

The Bridge Pattern is classified as a structural design pattern.

 

 

PURPOSE
Creational
Structural
Behavioral
Scope
Class

Factory Method

Adapter (class)

Interpreter

Template Method
Object

Abstract Factory

Builder

Prototype

Singleton

Adapter (object)

Bridge

Composite

Decorator

Façade

Flyweight

Proxy

Chain of Responsibility

Command

Iterator

Mediator

Mermento

Observer

State

Strategy

Visitor

 

 

Motivation

 

Discussion

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.

 

CODE example

//Abstraction class

abstract class Abstraction{

protected Implementor imp;

public void operation()

{

 

//Default implementation is provided here;

}

 

//Implementation is provided by child classes.

public abstract Implementor getImplementor();

}

class RefinedAbstraction extends Abstraction{

 

 

// Do the implementation here

public Implementor getImplementor(){

imp=new ConcreteImplementor();

return imp;

}

}

class Implementor{

public void operationImp(){

 

//Implement code here

}

}

 

//ConcreteImplementor class

class ConcreteImplementor extends Implementor{

 

//Override parent method

public void operationImp(){

 

//Implement the code here

System.out.println("This is an example of Bridge Pattern");

}

}

 

//Client

public class Client{

public static void main(String args[]){

Abstraction abs=new RefinedAbstraction();

Implementor imp=abs.getImplementor();

imp.operationImp();

            }

}

 

In the example given above, the Abstraction class contains a reference of ConcreteImplementor class. We can also use Abstract Factory to create get a concrete implementor.

 

Choose the right Implementor: It is important to decide how to select the Implementor class when there is more than one available. We can either keep a reference of all of them in the Abstraction class. But that will tightly couple Implementors with Abstraction and any addition in Implementor, would require code change in Abstraction class. So we can also have an Abstract Factory class to represent the hierarchy of ConcreteImplementors.

 

Bridges are scale-independent structures that apply in many object oriented situations. A Bridge also serves as an atomic element player in other design patterns.

 

Conclusions

It is easy to extend to cover different kinds of Windows or new platforms. Makes client code platform – dependent.

 

The three main benefits using this pattern are;