1 / 110

Chapter 6 Bridge

Chapter 6 Bridge. Summary prepared by Kirk Scott. Truss Bridge. Cable-Stayed Bridge, Fan Design. Cable-Stayed Bridge, Harp Design. Tatara Ohashi Bridge , Japan. The “Yellow Train”, France-Spain. An Unusual Suspension Bridge. Design Patterns in Java Chapter 6 Bridge.

terrel
Download Presentation

Chapter 6 Bridge

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 6Bridge Summary prepared by Kirk Scott

  2. Truss Bridge

  3. Cable-Stayed Bridge, Fan Design

  4. Cable-Stayed Bridge, Harp Design

  5. TataraOhashi Bridge, Japan

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

  7. Design Patterns in JavaChapter 6Bridge 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. 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. 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. 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. 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. 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. 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. 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. 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

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

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

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

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

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

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

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

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

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

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

  33. 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?

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

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

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

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

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

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

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

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

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

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

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

More Related