Bridge

1
Bridge
Structural Design Pattern

• SDD 22 Sep 2003
• Ian Dundore

2
What?

• Bridge is a structural object pattern.
• Defines a way to compose an object in order to
  produce greater functionality.
• AKA Handle or Body
• In particular, the Bridge D.P. is designed to
  enhance flexibility without significantly
  increasing complexity.

3
So?

• The core of bridge is one concept
• Separate the implementation of an abstract
  interface from the abstract interface itself.
• This allows the implementation and the
  abstraction to vary independently.
• That is, you can (theoretically) modify or
  extend one without modifying the other.

4
But

• Bridge is an alternative to inheriting the
  abstract interface directly.
• The reason for this is to separate the
  implementation details of the interfaces basic
  functions from the more complex functions derived
  from them.
• Inheritance binds the implementation details to
  the derived classes irrevocably. Bridge solves
  this problem.

5
How?

• Instead of inheriting a given abstract interface
  directly and re-implementing its basic functions,
  define an abstract implementation interface,
  and compose the given abstract interfaces
  functions of calls to the implementation
  interfaces functions.
• Then compose derivations of the given abstract
  interface from the basic functions in that
  interface.
• And also create subclasses of the abstract
  implementation interface that define concrete
  behavior for the implementation interfaces
  functions

6
That was confusing.

• Heres a diagram.

Implementation OpImplementation()
AbstractInterface SomeOperation()
Imp-gtOpImplementation()
ConcImplementation1 OpImplementation()
ConcImplementation2 OpImplementation()
Refinement RefinedOperation()
SomeOperation()
7
When?

• The Bridge pattern was meant for
• Situations where you want to avoid permanently
  binding abstract operations to their
  implementation details.
• Perhaps you want to switch between
  implementations at load-time or run-time.
• Example Graphics contexts Bridge could allow a
  user to choose between OpenGL or DirectX
  implementations.
• Both the abstraction and implementation must be
  extensible separately.

8
When? (cont.)

• An implementation needs to be shared among
  multiple objects, invisibly.
• Example a String class in which multiple objects
  must share a certain string representation.
• An implementation should be changeable without
  changing (recompiling) the abstraction
• Hardware drivers, which cannot change the
  operations theyre given by the hardware, but may
  need extension anyway.

9
Consequences

• Segregates interface and implementation.
• Implementations can be selected and configured at
  run-time.
• Compile-time dependencies between the interface
  and implementation are eliminated.
• Easier extensibility.
• For the abstraction, additional functionality can
  be composed of existing basic operations.
• For the implementation, new implementations can
  be added and old ones extended without disturbing
  the abstraction.

10
Consequences (cont.)

• Makes implementation details invisible.
• Truly encapsulates implementations into
  abstractions, thus hiding all the details of
  implementation from a client.
• The goal of encapsulation!

11
Caveats

• Only one Concrete Implementor?
• Creating an abstract Implementor class isnt
  necessary here.
• The abstraction can still be useful if you intend
  to
• Add new implementations
• Extend the implementation
• It also eliminates the need to recompile the
  abstraction if the implementation changes
  always good.

12
Caveats (cont.)

• How to choose the right Implementor
• If the abstraction knows about all the
  ConcreteImplementors, it could choose between
  them in its constructor.
• Eliminates compile-time decoupling benefit.
• Prevents transparent addition of new Implementors
• Choose a default ConcreteImplementor initially,
  switch it as necessary.
• Can be inefficient, but good for storage classes.
• Delegate the decision!
• Use the Abstract Factory design pattern.
• Absconds the Abstraction from knowing about
  Implementors.