Factory Method, Abstract Factory, and More Making the Concrete Abstract

Open/Closed Principle Brain surgery is not necessary when putting on a hat Yes, you can have it both ways

Open/Closed Principle (OCP) Classes should be open to extension, but closed to modification Extension Composition of abstract types, not concrete classes Constructors and setters also take those abstract types Composer delegates to the composed Inheritance from those abstract classes and interfaces Modification Editing – allowed for fixing bugs, but not adding behavior Danger: propagation of changes to numerous dependents (subclasses, aggregators) Costly invalidation of test cases (have to rewrite) “Closure” is really creating openings for extension There is no “close” operation, but can use version control

OCP in Strategy Also, a constructor that initially sets tires field. Note that KiaSoul delegates to Tire Open to infinity of tires without modification <<interface>> _____Tire_____ int size() bool perf() String season() _MichelinPilot_ … _DunlopSP_ … … _____KiaSoul_____ Tire tires_________ int tireSize() bool tirePerf() String tireSeason()

OCP for Observer Also, Display constructor that takes Subject, and Subject register method that takes Observer Subject delegates to the Observer Open to adding observers without modification composes abstract type <− inherits abs. type

OCP for Decorator Open to addition of new drinks and condiments without modification to support all combinations Inheritance from abstract types Composition of abstract types Decorator delegates to abstract superclass

Does this diagram indicate OCP? Yes (and why?) No (why not?)

Discussion Best answer: A. Because Client composes an abstract interface, it can accept any implementation of Target. Thus, it is possible to add new Adapter/Adaptee pairs to the design without modifying any existing classes. Not B. Some people noted that Adapter, a concrete class refers to a concrete class. But that is not the part of the design we need “open”. I can always code new Adapter/Adaptee pairs, if necessary.

Factory Pattern: Motivation Correctly making objects is complex Especially making collection of related objects Parts of a car Look-and-feel of a window: canvas, scrollbar, etc. The correct making of objects is not easily centralized in one place Often do it all over code wherever object is needed Violates SRP and DRY DP angle is that “new” names and makes a concrete class; should be referring to abstract concrete class has to be named, but we can at least hide that from most of system encapsulating class will violate OCP, but no others will

Factory is the answer Actually a collection of patterns Simply factory (idiom) Factory Method Abstract Factory (not today) Concrete class; Mystery how to make one

2¢ Factory for Dating Events … static “Factory” methods keep Event details local

What’s wrong with 2¢ Factory? Doesn’t hide construction details adequately Should pass an enum argument rather than defining multiple methods: Event.makeEvent(SEEMOVIE) Violates the Open/Closed principle “make” methods shouldn’t be static Name prefix should be “create”, not “make” C: No delegation to an abstract class. No CLASS. And geez, the methods are STATIC.

Simple Factory (idiom) How to make Events not necessarily part of Event

Comparison – increasingly abstract class MyDatingClass { … Event event = new Event(2, “OrderFlowers”); // magic constants // concrete Event class (majorly violates OCP) Event event = Event.makeOrderFlowers(); // abstract class object (passed into constructor) Event event = factory.createEvent(FLOWERS);

Class Diagram for Simple Factory

What’s wrong with Simple Factory? create method has to know about all the concrete classes it new’s Client class composes concrete class Factory is a concrete class A: sure, but unavoidable B: Yes: SPF should implement SPF Interface, PS should compose it C: No: The factory itself has to be concrete so it can be instantiated and its methods called

Simple Factory is Good, but not OCP SimpleEventFactory should implement EventFactory interface Clients of SEF should then compose EventFactory: class DateClass { private EventFactory factory; public DateClass(EventFactory factory) { this.factory = factory; } … Someone can implement a new class with EventFactory interface, and DateClass can use it with no modification Means that when EventFactory is extended (new subclass), DateClass is extended with new EventFactory options. That’s open for extension!

Factory Method Style: Date as Factory ____Date____ createEvent() ____Youth____ createEvent() ____Senior___ createEvent() … Subclasses of Date are the factories! In this example, no parallel Date/Event class hierarchy Event hierarchy is “flat” – class hierarchy is implicit in data of Event What changes is time to first “flowers” event, what the flowers are, etc.

Factory Method Style: Separate Factory Separate Factory like SEF but in hierarchy with abstract super Super centralizes Event selector Subs implement making

Factory Motivation for Pizza Example: Franchising

Factory Method Class Diagram “composes” them all because their constructors are referenced

Object Relationships