Design Patterns: Template Method, Strategy, State, Bridge [HFDP, Ch. 8] Say we have two classes whose code looks similar, but isn t identical. We can duplicate the code, but change it where changes are needed. Is this a good idea? Outline for Lecture 25 I. The Template Method pattern II. Template Method vs. Strategy III. State vs. Strategy IV. Bridge Template Method pattern is a way of abstracting similar behavior in various classes and duplicating only the code that differs. Here s the example given in the text (p. 282): Coffee void preparerecipe() { boilwater(); brewcoffeegrinds(); pourincup(); addsugarandmilk(); Tea void preparerecipe() { boilwater(); steepteabag(); pourincup(); addlemon(); Do you see the similarity? How might you avoid code duplication? Try to think of more than one way, and submit your answer here. How should we write the code? Fill in the blanks here. public { preparerecipe() { boilwater(); ; pourincup(); ; Lecture 25 Object-Oriented Languages and Systems 1
What other declarations do we need in this class? void boilwater() { System.out.println("Boiling water "); void pourincup() { System.out.println("Pouring "); ; ; What methods do the Coffee and Tea classes need to implement? Now, let s draw the class diagram, like it says in the book This is the Template Method pattern. Which method in it is a template method? Now, let s write up the pattern definition like we have done for other patterns before. Template Method Intent: Capture common parts of an algorithm in a single code sequence. Problem: Solution: CSC/ECE 517 Lecture Notes 2009 Edward F. Gehringer 2
Implementation: Can you think of other examples of Template Method? One of the main pitfalls in Template Method is that sometimes processes are almost the same, but not exactly. Certain steps need to be performed in some cases, but not in others. For example, in the coffee case, a customer may not want sugar and milk. What s the best way to address this? Our code now becomes public abstract class CaffeineBeverage { final void preparerecipe() { boilwater(); brew(); pourincup(); The hook method is given a default implementation, which can be overridden by subclasses. Lecture 25 Object-Oriented Languages and Systems 3
Template Method helps avoid the pitfall of dependency rot. This means that high-level components (methods of the abstract class) depend on low-level components, as well as vice versa. In this context, what does it mean to depend on? Why would this be bad? The dependency-inversion principle says, Depend on abstractions. Do not depend on concrete classes. What example of the dependency-inversion principle did we see in the last lecture? To prevent dependency inversion, we apply the Hollywood principle: How can this be realized in the Template Method pattern? How can we prevent the subclass methods from calling methods of the abstract class? One commentator goes even further. He says that multiple layers of Template Methods are inherently prone to the yo-yo effect. What do you think? Template Method vs. Strategy Recall the Strategy pattern from Lecture 13. In this case, you need to choose an algorithm for a task depending on some parameter of the situation. CSC/ECE 517 Lecture Notes 2009 Edward F. Gehringer 4
For example, consider quadrature (numerical integration) again. Each time you calculate the area of a region, you need to know what the function is that you are calculating the region underneath. The definition of Strategy from HFDP is, The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Let s provide a definition of Strategy in the format that we have used before. Strategy Intent: To decouple algorithms from the objects that use them. Problem: Solution: Implementation: What s different about the two patterns? Lecture 25 Object-Oriented Languages and Systems 5
Strategy vs. State [HFDP, 10.10] Hmmm that s interesting. Strategy lets objects appear to change class. Isn t that what State does? How can we tell the difference between Strategy and State? Bridge [HFDP, 14.1] Now, let s look at the class diagram for the State pattern (for example, at http://www.exciton.cs.rice.edu/javaresources/designpatterns/statepat.htm). CSC/ECE 517 Lecture Notes 2009 Edward F. Gehringer 6
Note that the Context object holds a reference to an abstract class. This is the abstract class from which the concrete states are derived. It turns out that the same structure is valuable for implementing drivers. What s a driver? Drivers are generally used by various applications. Consider a printer driver, for example. There is a driver for a particular printer for each OS. Many different applications can use that printer, providing that the right driver is present. This is an example of the bridge pattern. We have various abstractions (the applications) and various implementations (the drivers). If the applications aren t in a hierarchy, the class diagram for Bridge is exactly the same as the class diagram for State. But often, the abstractions are in a hierarchy. HFDP gives the example of televisions and remotes. TVs have behavior in common, and so do remotes. If they re universal remotes, they can be used by lots of different kinds of TVs. This leads to the UML diagram on p. 613 of HFDP, or view it online. What are the advantages of Bridge? OK, we just told you the right way to handle this problem. What would be the wrong way? Can you imagine using a lot more subclasses? So one way of looking at Bridge is that it avoids unnecessary subclassing. Let s describe the pattern. Bridge Intent: To decouple interfaces from the implementations that use them. Lecture 25 Object-Oriented Languages and Systems 7
Problem: Solution: Implementation: Can you think of other examples of Bridge? CSC/ECE 517 Lecture Notes 2009 Edward F. Gehringer 8