1. Unit 23 Bridge Summary prepared by Kirk Scott 1

2. Truss Bridge 2

3. Cable-Stayed Bridge, Fan Design 3

4. Cable-Stayed Bridge, Harp Design 4

5. Tatara Ohashi Bridge, Japan 5

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

7. Design Patterns in Java Chapter 6 Bridge Summary prepared by Kirk Scott 7

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 8

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 9

10. Eliminating Duplication The design pattern is structurally more clever than that It has the effect of eliminating unnecessary duplication in the implementation code 10

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 11

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 12

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 13

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 14

15. 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 16

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 17

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 18

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 19

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? 20

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.” 21

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 22

23. 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 24

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 25

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 26

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.” 27

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 28

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

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 30

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 31

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 32

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 33

34. 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 CS 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 CS 202 35

36. 36

37. The book’s example and the CS 202 example are analogous in structure The only difference is that the CS 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? 37

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 38

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 39

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

41. 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 42

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 43

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 44

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 45

46. 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 47

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 48

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 49

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 50

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 51

52. This solution is shown on the following overhead 52

53. Solution 6.4 53

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 54

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 55

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 56

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 57

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 58

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 59

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 60

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 61

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 62

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 63

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 64

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 65

66. 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 67

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 68

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 69

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 70

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 71

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 72

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 73

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 74

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 75

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 76

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. 77

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 n th time 78

79. 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 80

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 81

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 82

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 83

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 84

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 85

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 86

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 87

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 88

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’ 89

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 90

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 91

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 92

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 93

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 94

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 95

96. 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 downward to implement taxability 97

98. 98

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 99

100. 100

101. Lasater’s UML Diagram If you study Lasater’s diagram, you’ll find that it corresponds with the examples given so far 101

102. 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 103

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 104

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 105

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 106

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? 107

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 108

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 109

110. The End 110