Program to an interface rather than an implementation is fine and good: - What about "new"? Goal: handle change well - Concrete class names in "new" expressions won't do this - As new classes are added, this code may have to be revisited. That is, creation code may also vary over time. - Thus, not "closed to modification". Pizza shop example - orderPizza method has creation code in it that may change as Pizzas change. But this should be independent of the code to actually produce a pizza. - Makes sense when creation code like this might be used in many places. - static vs. non-static? - static method in class: static factory pattern - "Simple Factory" is a "honorable mention" design pattern (p. 100). Factory Method Pattern: - Don't pass in the factory as an argument. Define it as an abstract method in the superclass, and let subclasses override it. - Because creation and operation are tied together, they belong in the same class. (Despite what the book says during abstract factory, it seems to me that having an implemented operational "template" in the superclass is a key to the Factory Method pattern; it can't just be an empty class with a single abstract method. See p. 135 that hints this.) See pizza pattern p. 120 - Parallel class hierarchies: a creator class goes along with a product family; in this case, the various kinds of pizza classes. Pattern diagram p. 134. Design Principle: Depend upon abstractions, no concrete classes. - Combats "Dependency Inversion". - Guidelines for adhering to this principle: - No variable's declared type should be a concrete class. - No class should derive from a concrete class (in the sense that you'd create objects of that class and use them in your program.) - No method should override an impleented method of any of its base classes. Abstract Factory (p. 156): a factory with many methods for creating related product families. - In the book, this is for creating related families of ingredients. - Don't quite believe the comparison on p. 160 and 161; AF is not really using FM.