1

Chapter 6Bridge

Summary prepared by Kirk Scott

2

Truss Bridge

3

Cable-Stayed Bridge, Fan Design

4

Cable-Stayed Bridge, Harp Design

5

Tatara Ohashi Bridge, Japan

6

The “Yellow Train”, France-Spain. An Unusual Suspension Bridge.

7

Design Patterns in JavaChapter 6

Bridge

Summary prepared by Kirk Scott

8

The Bridge Pattern—Identifying Abstraction in a Design

• The Bridge design pattern, like many others, is based on identifying abstraction in an application

• When the abstraction is identified, it is factored out and implemented separately

• In other words, the design pattern leads to an abstract class or more likely, a Java interface

9

The Bridge—More than just an Abstract Class or Interface

• When you see a UML diagram of a set of classes which implement the Bridge design pattern, you will note the following– It consists of more than just implementing an

abstract class at the top of a hierarchy– It consists of more than just designing an interface

and implementing the interface in various classes

10

Eliminating Duplication

• The design pattern is structurally more clever than that

• It has the effect of eliminating unnecessary duplication in the implementation code

11

The Bridge as a Driver

• The Bridge design pattern is also known as the Driver pattern

• This terminology arises in the context of database drivers

• It also arises in the context of printers and other computer devices, for example

12

• The term bridge is descriptive of how the structure of the pattern looks in UML

• The term driver is descriptive of the functionality of the pattern in an application context

13

Bridge

• Book definition: The intent of the Bridge pattern is to decouple an abstraction from the implementation of its abstract operations, so that the abstraction and its implementation can vary independently.

• Comment mode on:• I don’t find this statement very helpful• I don’t think the idea becomes clear until an

example has been developed

14

An Ordinary Abstraction: On the Way to Bridge

• The book reviews the general ideas of abstraction in class and hierarchy design as a basis for taking up the Bridge pattern

• The UML diagram on the following overhead shows two different machine controllers for two different kinds of machines

15

16

• The controller classes have some methods that probably have the same functionality even though they have different names

• The usual explanation of the difference in method names applies

• The classes come from different sources

17

• For example, the machines may be made by different manufacturers

• The manufacturers supply the software needed to integrate the machines into an automated production system

• For this reason, the implementations of the given classes can’t be changed

18

Creating a Common Superclass

• It would probably be both conceptually and practically desirable to create an abstract superclass for the machine controller classes

• The superclass would potentially contain constructors and some concrete methods that the subclasses could inherit

19

You Can’t Build a Hierarchy Up—Only Down

• It would also contain abstract declarations of common methods which the subclasses would implement

• However, if the class implementations can’t be changed, building a hierarchy above them in this way can’t be done

20

Bridges are Adapters

• Challenge 6.1• “State how you could apply a design pattern to

allow controlling various machines with a common interface.”

• Comment mode on:• This challenge stems immediately from the

foregoing observation about the classes• The question is, how do you abstract out a common

interface when you can’t change the classes themselves?

21

• Solution 6.1• “To control various machines with a common

interface, you can apply the Adapter pattern, creating an adapter class for each controller.

• Each adapter class can translate the standard interface calls into calls that existing controllers support.”

22

• Comment mode on:• Although the book didn’t state this in advance,

it becomes apparent that the Bridge pattern is building on the Adapter pattern

• The UML diagram on the following overhead shows the current state of development of the introductory scenario

• It is followed by commentary

23

24

• At the upper left, the abstract MachineManager class defines the common interface, ultimately for controllers

• The MachineManager class has abstract methods as well as one concrete method

• The MachineManager class doesn’t connect directly with the controller classes

25

• At the bottom of the design are two other new classes, FuserManager and StarPressManager

• These classes are subclasses of MachineManager

• These classes have a reference to a FuserController object and a StarPressController object, respectively

26

• What the UML diagram shows is two occurrences of the Object Adapter design pattern

• The original scenario just started with two distinct controller classes

• In the new design there is an abstract manager class and concrete classes FuserManager and StarPressManager

• There are two occurrences of the Adapter design pattern

• Each of the concrete classes adapts one of the two different controller objects

27

The Code for a Bridge may have Something in Common with a Decorator

• Challenge 6.2• “Write a shutdown() method that will stop

processing for the MachineManager class, discharge the bin that was in process, and stop the machine.”

28

• Comment mode on:• Note carefully that this challenge is requesting

the implementation of a concrete method in the abstract superclass

• As usual, without problem domain knowledge it’s difficult to predict exactly what the answer will be

29

• Solution 6.2• public void shutdown()• {• stopProcess();• conveyOut();• stopMachine();• }

30

• Comment mode on:• The code illustrates an important technique that

we’ve seen before in the Decorator pattern• It is possible to implement a concrete method in

the abstract superclass that calls abstract methods in the superclass

• These calls to abstract methods in the superclass rely on the implementations of the methods in the subclasses

31

• Polymorphism and dynamic binding are at play again

• When the concrete method inherited from the abstract superclass is called on a subclass object, the calls inside are determined by the subclass type

• Ultimately, the implementations of the methods in the subclasses rely on the methods in the adapted objects

32

Adding Another Layer to the Hierarchy

• The collection of classes introduced so far is based on a MachineManager class and subclasses FuserManager and StarPressManager

• In other words, there is a hierarchy based on different kinds of machines

• Suppose you want to introduce a new kind of concept, that of a machine manager that includes a handshaking functionality

33

• Handshaking refers to the idea of passing status messages back and forth

• In addition to handshaking machine managers, you’d like to keep the old, non-handshaking machine managers

• Let handshaking be abbreviated Hsk in class names

• The following UML diagram illustrates the new class hierarchy

34

35

Another Layer in the Hierarchy and Interfaces

• Before going any further with the book’s explanation, notice that a picture like this came up in CSCE 202

• The idea was that there was an inheritance hierarchy of foods, and you also wanted to implement the concept of taxability

• Since Java doesn’t support multiple inheritance, taxability was done with an interface

• The following UML diagram illustrated this in CSCE 202

36

FoodV5

PackagedFoodV5 BulkFoodV5

TaxedPackagedFoodV5 TaxedBulkFoodV5

«interface»Taxable Interface

37

• The book’s example and the CSCE 202 example are analogous in structure

• The only difference is that the CSCE 202 example explicitly identifies an interface

• The thing that should strike you at this point is that something is wrong

• Namely, how come, when implementing an interface, every subclass in the inheritance hierarchy has to have a new subclass?

38

Duplication in the Design

• According to the object-orientation brainwashing, using object-oriented concepts like inheritance, you shouldn’t have to re-implement common things

• But in this case, every taxable subclass, or in the book’s example, every handshaking manager class, will have to implement taxability/handshaking

39

• Even though the subclasses are different, it is highly likely that for many of the subclasses, the implementing code will be largely the same

• In other words, so much for eliminating duplication

40

• The book’s UML diagram is shown again below for reference

41

42

Common Methods in the Design

• The book’s diagram shows a setTimeout(:double) method in both HskFuserManager and HskStarPressManager

• The book points out that this is a good example of a method which may be exactly the same in both

• It can’t be pushed up higher in the hierarchy because the superclasses of Hsk classes are non-handshaking classes without this characteristic

43

• Abstracting setTimeout() into an interface also doesn’t solve the problem, because interfaces don’t contain implementations

• You still need separate subclasses• If the number of subclasses increases, two

practical problems result

44

What’s Wrong with Repeated Code?

• 1. You have to write duplicate code x times• This is not too bad because you can just copy and

paste• 2. If the design and implementation change in the

future, you have to remember that there were x places with common code and change each of them

• Copy and paste helps with the mechanics, but keeping track of where repetition occurs in designs is not pleasant

45

Solving the Problem with a Bridge

• The book does the solution with challenges• As usual, it’s easiest to just work through the

solution• The UML of the problematic design is shown

again on the following overhead• The problem lies in the extension of the

hierarchy into multiple handshaking classes

46

47

Preliminary Description of the Solution

• The solution using the Bridge pattern does two things:

• 1. It implements the common, generic machine management functionality of handshaking in a single, simple inheritance hierarchy

• There is a machine manager superclass and a handshaking machine manager subclass

48

• 2. It handles the non-handshaking aspects of machine management with a common driver interface

• There are different driver classes which implement the interface for each kind of machine

• The driver classes are not literally the machines, but they are the manifestations of the machines in the software

49

• This is the relationship between the machine manager inheritance hierarchy and the interface and implementing classes:

• An instance of a machine manager has a reference to an instance of a specific machine driver

• By inheritance, an instance of a handshaking machine manager also has a reference to an instance of a specific machine driver

50

• In short, what is happening is object adaptation

• It is multiple object adaption because you adapt to an instance of something which implements the driver interface

• In fact, there are multiple actual classes which implement that interface

51

• The desired result is this:• You can have a non-handshaking machine

manager for any different kind of machine• You can have a handshaking machine manager

for any different kind of machine• You only have to write one handshaking

subclass in the machine manager hierarchy• You don’t have to write a handshaking subclass

for every kind of machine

52

• This solution is shown on the following overhead

53

Solution 6.4

54

Describing the Solution in Greater Detail

• Initially, this detailed explanation will be repetitive

• But it will eventually segue into ideas that haven’t been raised before

• For the purposes of the discussion, consider the two halves of the solution in terms of the left hand side and the right hand side of the UML diagram given

55

The Left Hand Side

• On the left hand side, the MachineManager2 class remains as a superclass (the 2 is just a version number)

• A hierarchy grows underneath it• This is not the hierarchy of different machine

manager classes for different kinds of machines• It is a hierarchy with one subclass, the machine

manager subclass with handshaking, HskMachineManager2

56

• The book’s example never introduced the idea of a handshaking interface, but my example did have a taxability interface

• It is worth noting that the concept that was captured as an interface in my example becomes a superclass/subclass relationship in the bridge solution

57

The Reference

• The MachineManager2 class differs from the MachineManager class because it has a reference

• It refers to something which implements the new interface which appears in this design, the MachineDriver interface

• The reference is analogous to the reference to an object in the object adapter design pattern

58

The Right Hand Side

• The MachineDriver interface appears at the top of the right hand side of the diagram

• This is the type of thing referred to in the bridge design pattern

• Depending on your point of view, the reference itself might be considered the bridge

• Or the interface on the right hand side (or abstract class, if that is used) is the bridge

59

• The name of the interface contains the word “driver”

• The interface could also have been named MachineBridge

• The MachineDriver interface makes it possible for the MachineManager2 class to use instances of any kind of machine

60

More about the Driver, or Bridge Interface

• The MachineDriver interface contains method definitions that are common to the management of different kinds of machines

• Underneath it in the diagram are classes named FuserDriver and StartPressDriver that implement the MachineDriver interface

• Structurally, what was the class hierarchy in the original design is now converted to an interface and implementing classes in the new design

61

• The original design had an inheritance hierarchy based on machine manager type

• In the new design the abstractions corresponding to different kinds of machines don’t appear in an inheritance hierarchy

• Instead, the different machine drivers, those abstractions which represent different machines, implement a common interface

62

How the New Design Works

• An instance of plain MachineManager2 doesn’t have handshaking

• It is a manager of a fuser, for example, by virtue of the fact that it has a reference to an object of FuserDriver, which implements the MachineDriver interface

• The same kind of explanation applies if it’s a manager of a StarPress

63

• The same logic applies for an instance of HskMachineManager2

• In the diagram, the reference arrow only appears between MachineManager2 and MachineDriver

• However, HskMachineManager2 is a subclass of MachineManager2

• Therefore, an instance of the subclass would also have an inherited reference to MachineDriver

64

• An instance of HskMachineManager2 does have handshaking

• It is a handshaking manager of a fuser, for example, by virtue of the fact that it has a reference to an object of FuserDriver, which implements the MachineDriver interface

• The same kind of explanation applies if it’s a manager of a StarPress

65

• In summary, instances of both MachineManager2 and HskMachineManager2 manage a certain kind of machine by virtue of the specific kind of driver they have a reference to

• The UML diagram is shown again on the following overhead

66

67

The Bridge Pattern and Decoupling

• The bridge pattern is based on decoupling the concepts of machines and managers

• On the left hand side, the hierarchy based on machine manager types can grow and change

• On the right hand side, the interface and implementing classes based on machine types can grow and change

68

• The two sides can grow and change independently

• Changes on one side don’t require (multiple) changes on the other

• There is a decoupling between the abstraction of a machine manager and the implementation of its abstract methods

69

Changes in the Location of Methods Due to the New Design

• In the design given at the beginning of the chapter, the MachineManager class was abstract and contained abstract methods

• Subclasses for managers of specific kinds of machines implemented those abstract methods

• In the latest design, the MachineManager2 class is not abstract

70

• All of the abstract methods that had been in MachineManager no longer exist in MachineManager2

• The declarations of all of those methods have been moved to the MachineDriver interface

• In other words, the abstract methods have become methods in the bridge interface

71

• This is how the separation, or decoupling of the pattern is accomplished

• In the original design the machine manager sat above a hierarchy of classes that concretely implemented the abstraction of different kinds of machines

• The machines have moved to the right hand side of the design, so the methods associated with them can be moved to the interface above them

72

• All that remains in the machine manager are methods intrinsic to management

• These can be inherited by the handshaking subclass, which also contains purely management code

73

• Notice this:• The handshaking subclass also relies on object

adaptation• We’re not looking at the internals of the code on

the left hand side, but this much is apparent:• The implementation of methods would wrap calls

on the object reference contained• In the handshaking subclass, the wrapping would

include the handshaking logic

74

Again, the Decoupling Allows the Two Sides to Grow Independently

• Moving the abstract, machine management methods which are machine specific out of the machine manager class and into the machine driver interface has two results:

• On the left, the machine management hierarchy can grow based solely on machine management characteristics like handshaking

• On the right, the driver/machine ‘hierarchy’ can grow to an arbitrary number of different kinds of machines

75

Defining the Term Driver More Specifically

• MachineManager2 has a reference to an object of the type MachineDriver

• The MachineDriver interface is designed for the use of the machine manager

• The book expresses the relationship as a form of adaptation

76

• To paraphrase the book: The concrete driver classes that implement the driver interface adapt specific kinds of machines to the requests of managers

• Keep in mind that the UML diagrams only show the bridge part of the pattern

• Ultimately, on the right hand side, there would also be machine classes in the picture

77

• The concrete classes, FuserDriver and StarPressDriver, are the actual drivers

• Finally, this is the book definition of a driver:• A driver is an object that operates a computer

system or an external device according to a well-specified interface.

78

Drivers as Bridges

• The book also makes this statement, which explains the relationship between a bridge and a driver:

• Drivers provide the most common example of the Bridge pattern in practice.

• Look at the UML diagram of the new design for the nth time

79

80

Drivers as Adapters

• Adapter like characteristics can be seen at two levels in this example

• You can view the left hand side as if it had a client (which is not shown) which uses managers

• The manager classes adapt the drivers to the client

81

• On the right hand side, each driver is also an instance of the Adapter pattern

• The client in this case is a machine manager, whether handshaking or non-handshaking, which manages a machine

• Each concrete machine driver class implements the machine driver interface, adapting a particular kind of machine to the client

• What’s not shown in this case are the machine classes which the drivers adapt to

82

Application Development

• This view of bridges/drivers leads to some higher level observations about object-oriented design of software systems

• Introducing the interface into the design decouples machine manager development on the client side from the development of specific machine drivers

• However, the two sides aren’t completely independent

83

• Conceptually, you might define the driver interface needed by the client first

• Then develop drivers that implement the interface• Alternatively, the driver functionality might be the

leading element of the design• Then it becomes necessary to develop an abstract

model (interface) for the machine(s)/system(s) to be driven

• When the interface is defined, then the drivers can be rewritten to conform to it

84

A Limitation to this Approach

• The limitation of the bridge/driver approach has to do with the design of hierarchies and interfaces in general

• The limitation is not specific to bridges, but it is apparent with them

• Remember the observation at the beginning of the chapter:

• You can build hierarchies down, but not up

85

• You can define a driver interface• You can write the individual drivers• But ultimately, the drivers drive separate

machines• These machines may come from different

suppliers• They may have machine code with varying

methods• You are adapting to them

86

• When the common interface is designed, the idea is that every method in the interface should apply to each driver class that implements it

• However, by definition, machines differ from each other and each one may have unique methods of its own

• Therefore, the driver for such a machine may or may not be able to support all of the methods in the common interface

87

• This leads to a design decision involving two less than ideal alternatives

• This idea has come up indirectly in reference to patterns discussed earlier, but it is critical now

• 1. If there are methods that are not in common, don’t put them in the interface.

• 2. Put all methods in the interface, including those that are unique to certain machines

88

• Under alternative 1, individual machines will have capabilities that a client, a machine manager, can’t control through calls to methods in the interface, because the methods aren’t in the shared interface

• The solution to this problem is to write special case code in the machine manager

• This code would have to check whether an object was an instance of a given class before calling on it a unique method belonging only to that class

89

• Under alternative 2, in the driver classes, you have to include dummy or bogus implementations of those methods for the classes that they don’t apply to

• This eliminates the need for checking code in the client

• It does imply that the client code needs to be written under the assumption that for some method calls ‘nothing may happen’

90

Database Drivers

• An everyday example of the use of drivers in software arises in the database world

• You may have seen the acronyms ODBC and JDBC

• They stand for open database connectivity and Java database connectivity

• They are standards that make it possible to mount and use different database systems in a given computer environment

91

• JDBC can be briefly described as an application programming interface for running SQL statements

• The key word in the previous statement is ‘interface’

• The API defines a set of valid database calls that an application program can execute

92

• A JDBC compliant dbms driver implements the interface and supports the calls

• There is a separate driver for each different dbms that is supported

• These drivers adapt the interface method call to the native call in the dbms that supports it

93

Reality is Complex

• The previous discussion was conducted as if the client is a single class, there is one driver/adapter, and one underlying “thing” that is adapted to

• Reality can be more complex• Complexity on the application side is the

application programmer’s concern

94

• Complexity on the driver side should not be the application programmer’s concern.

• This is the concern of the organization that produced the drivers

• In the db world, drivers are things that are givens, and the application programmer either uses them or not, but doesn’t develop them

95

• JDBC may have drivers that adapt to more than one database, for example

• All the application programmer has to worry about is a single instance of the driver and the interface for making calls to it

• The diagram on the following overhead gives a simple overview of the situation

96

97

Another Example

• The other example won’t be pursued in depth• It simply tries to apply the book example’s

adapter logic to the food hierarchy• The UML diagram on the following overhead

shows an application where the food hierarchy grows downwards to implement taxability

98

FoodVX

PackagedFoodVX

-adaptedPF : PackagedFoodVX

AdaptedPackagedFoodVX

-adaptedBF : PackagedFoodVX

AdaptedBulkFoodVX

BulkFoodVX

«interface»Taxable

TaxedAdaptedBulkFoodVX TaxedAdaptedPackagedFoodVX

AdapterTestProgamVX

99

• The UML diagram on the following overhead shows the redesigned application

• The Taxable interface in the original design becomes a subclass on the left hand side of the new design

• The different kinds of foods, bulk and packaged, implement a food interface on the right hand side

100

AdaptedFoodVY

TaxedFoodVY

«interface»FoodVYInterface

BulkFoodVY PackagedFoodVY

FoodVY

«interface»Taxable

BridgeTestProgramVY

101

Lasater’s UML Diagram

• If you study Lasater’s diagram, you’ll find that it corresponds with the examples given so far

102

103

The Remainder of the Chapter

• The rest of the chapter continues the topic of JDBC database drivers

• It will not be covered in class• This is a topic which could be pursued at

greater length in a database class• Students can read the sections in the book if

they want to

104

Summary

• The Bridge pattern ultimately results from abstraction in a design and a need to ‘factor’ in more than one way

• Given an abstract class (with abstract methods) the time may come when you would like to extend it in an orthogonal hierarchy

• Java doesn’t support multiple inheritance, so that is not directly possible

105

• The Bridge pattern means that the abstract methods are moved into an interface

• There can be more than one class that implements the interface

• These classes would have been subclasses of the original class in the old design

• In the new design, the original class then makes use of an object that implements the interface

• In the new design, the new hierarchy can be implemented as subclasses of the original class

106

• Specifically, the abstraction and its implementation have been decoupled

• More generally, it’s clear that there can be an unlimited number of classes that implement the new interface

• Plus, the new hierarchy can grow as needed• Subclasses of the new hierarchy will be able to use

objects that implement the interface• This is because the subclasses will inherit the reference

to such objects from the original class, which now has a reference added to it

107

• The end result of all this is not having to duplicate method code because one hierarchy is laid over another

• On the other hand, you also have to deal with the problem of methods that are unique to individual classes that implement the hierarchy

• Should they be left out of the interface?• Or does it make sense to include them in the hierarchy

even though some or most of the implementing classes will have to provide bogus implementations of those methods?

108

• Drivers are the most common example of the application of the Bridge pattern

• Database drivers provide a good software example of drivers

• Database drivers illustrate the trade-off between using drivers and not using drivers

• Drivers give you flexibility and generality• Drivers may not support methods that are

unique to a given database

109

• Not using drivers means writing code specific to a given database

• On the one hand, this may mean being able to use unique features and getting good performance

• On the other hand, it locks your software into that specific database

• It is not always clear which choice is better, but it is important to be aware of the trade-off when making the choice

110

The End