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

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

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

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

5. What’s wrong with 2 ¢ Factory? A. Doesn’t hide construction details adequately B. Should pass an enum argument rather than defining multiple methods: Event.makeEvent(SEEMOVIE) C. Violates the Open/Closed principle D.“make” methods shouldn’t be static E.Name prefix should be “create”, not “make” 5

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

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

8. Class Diagram for Simple Factory 8

9. What’s wrong with Simple Factory? A.create method has to know about all the concrete classes it new’s B.Client class composes concrete class C.Factory is a concrete class 9

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

11. Factory Method Style: Date as Factory  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. 11 ____Date____ createEvent() ____Youth____ createEvent() ____Senior___ createEvent() …

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

13. Factory Motivation for Pizza Example: Franchising 13

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

15. Object Relationships 15

16. Adapter Pattern Again? Composition and Delegation, again? 16

17. Adapter: Motivation 17 Real-world examples: Database connectors Chat systems Adapter: Uses Composition and Delegation Adapter (wrapper) is not subclass of wrapped object (because we’re adapting) Naming: InputStreamToReaderAdapter

18. Adapter: Example 18

19. Adapter: Class Diagram  All the classic DP elements:  Client is “open” because it composes interface  Adapter implements interface, delegates to concrete class 19

20. Adapter: Exercise  Java’s StringTokenizer class breaks a string into words using a specific algorithm  Oddly, it implements the Enumeration interface instead of Iterator interface  Need to pass the StringTokenizer to a class that requires (takes) an Iterator  Write an adapter from Enumeration to Iterator  (Could do this for StringTokenizer, but that’s less reusable!)  interface Enumeration { boolean hasMoreElements(); E nextElement(); }  interface Iterator { boolean hasNext(); E next(); } 20

21. Adapter Exercise (solution) 21 USE: Iterator iter = new EnumerationIterator (myStringTokenizer); while(iter.hasNext()) { String str = iter.next(); System.out.print(str + " "); }

22. Which pattern does this class diagram call out for? A.Strategy B.Decorator C.Adapter D.Factory 22

23. Façade It’s all a…oh, nevermind. 23

24. Façade – variant of adapter  Not for matching incompatible interfaces, but for simplifying use  Hide unneeded operations  Combine low-level operations into convenient one  Combine several objects into one object  Android’s AnimationUtils is an example 24

25. Façade - Example  Composes three classes  Groups low-level operations into high-level  Façade doesn’t have to be interface (but if it does, it will be adapter, too)  Note: if low- level classes declared as interfaces, then becomes Strategy, too 25

26. Which pattern? Suppose we extended myCity to provide a graph of friend proximity over the whole day. We’d start with a simple display, but think we’ll eventually adopt a powerful library to support a glanceable, informative display. Which pattern should be applied? A.Strategy B.Decorator C.Adapter D.Façade E.Factory 26

27. Discussion  Adapter : graphing library probably incompatible with initial service  Façade : to hide complexities of the powerful libraries  Decorator : to add border, extra info, around graph view  Strategy : to give users choice of graph  Qualities of strategy pattern in Adapter also facilitate testing  Factory : making variants of display for different modes/views  Do all? Agile says wait-and-see (refactor), as DPs take time and add complexity  Still, should compose abstract types ( interfaces and abstract super classes ) in initial design  almost free  will save writing new testcases  sets the stage for quick use of DPs later 27

28. Limitations of Factory Method? A.YouthDate class depends on concrete Event class(es) – even if we subclass Event to YouthEvent B.Doesn’t cope with how the various parts (Events) of a Date compose – two dinners and no movie? C.Date classes know too much about events (violating SRP) – know details of making, like constants 28

29. Abstract Factory: Motivation  Need multiple cooperating methods  Sounds like a class!  Interface (or abstract superclass) and subclasses  Typically, each method is a factory method  Typically, each “part” is abstracted as an interface  NOTE: next example not equivalent to previous  Helps keep example simple 29

30. Abstract Factory - Example 30

31. Warning – simplified example  The examples today avoided the parallel class hierarchies by using the “flat” Event class  More complicated when you want the Product and Creator hierarchies to mirror each other  Still, essential idea of avoiding abstract classes referring to concrete classes  Key difference between Factory Method and Abstract Factory  Collection of related parts made to work together  Each gets own (factory) method  Aggregate these methods using a class, of course 31

32. What’s really wrong w/ Simple Factory?  Had said: Factory user doesn’t have to use Date class  Basically too flexible (for some applications)  Can use factory (& Event in general) in myDateClass A.Overkill for the job, just need a (factory) method, not a whole class B.Violates Open/Closed Principle C.It’s just fine as is D.Trick question: original answer was right 32

33. Simple Factory (idiom) 33