Bridge Design Pattern

1
Bridge Design Pattern

• Thanos Baskous Casey Shields

2
Bridge

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

3
Metaphor

• The object movement looks to the real world for
  insights into modeling software relationships.
  With these dual roots, it seems reasonable that
  software design patterns should be repeated in
  real world objects.
• Michael Duell, "Non-software examples of
  software design patterns", Object Magazine, Jul
  97, p54

4
Non Software Analogy

• There is an accountant at an international bank
• The Accountant tells customer what he needs,
  Accountant does business
• All is well

5
Problem

• The bank is an international bank
• A customer arrives who doesnt speak Accountants
  language
• No business can be done
• How do you solve this problem?

6
Do You?

• Teach the language to your accountant?
• Hire a new accountant who knows the language?
• Do this every time a new language arises, for
  each of your accountants?
• Of course not, too much work

7
Hire a Translator

• Now accountant can focus on banking and not
  learning how to speak to every possible customer
• The accountant doesnt have to be changed as
  customers are changed. Just have to have a more
  skilled translator
• Different accountants could use the same
  translator

8
Hire a Translator

• The translator is a bridge between the actual
  accounting and the implementation of it which is
  starting and maintaining accounts with new
  accountees by communicating to them

9
Problem

• When the implementation of your program changes
  new
• platform, new operating system, alternate methods
• implemented, et cetera
• Do you
• Extend every part of the program to work with the
  new implementation?
• Write new classes to deal with the new
  implementation?
• Do this every time your implementation changes?
• Of course not, too much work

10
Use a Bridge

• Now programmers can focus on refining the the
  abstraction and not re-writing the thing for
  every possible implementation
• The abstraction doesnt have to be changed as
  implementations are changed. Just have to have to
  update implementor
• Different abstractions could all use the same
  implementor

11
Examples

• Might have a data set whose implementation would
  be different depending on its size
• If the data set is small use a linked list
• If it is big change it to hash table
• Whatever is using the data set doesnt know this
• It simply adds, removes and searches for elements
  in the set

12
Examples

• 3.2 Bridge 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.
  
• Michael Duell, "Non-software examples of
  software design patterns", Object Magazine, Jul
  97, p54

13

• Client
• Object using bridge pattern
• Abstraction
• Defines abstract interface
• Maintains implementor reference
• Refined Abstraction
• Extends interface defined by Abstraction
• Implementor
• defines interface for implementation classes.
• Concrete Implementor
• Specific implementation

14
Bridge Advantages / Disadvantages

• Pros
• Abstraction and Implementation separated
• Runtime choice
• Less subclasses
• Interface and implementation can be varied or
  extended independently

15
BridgeAdvantages / Disadvantages

• Cons
• (C) Using multiple inheritance
• Slight performance impact
• (Degenerate case 1-1 ratio) Amount of coding

16
When To Use Bridge Pattern

• Multiple implementations
• Or more in the future
• Abstraction/Implementation independence
• No recompiling one for change in other, just
  re-linking
• Questions?