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

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

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

4. 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()

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

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

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

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

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

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

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

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

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

14. 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);

15. Class Diagram for Simple Factory

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

17. 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!

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

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

20. Factory Motivation for Pizza Example: Franchising

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

22. Object Relationships