© Kenneth M. Anderson, 2011CREATIONAL PATTERNSCSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGNLECTURE 25 — 04/12/20111Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Goals of the LectureCover material from Chapters 20-22 of the TextbookLessons from Design Patterns: FactoriesSingleton PatternObject Pool Pattern2Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Pattern ClassificationThe Gang of Four classified patterns in three waysThe behavioral patterns are used to manage variation in behaviors (think Strategy pattern)The structural patterns are useful to integrate existing cod into new object-oriented designs (think Bridge)The creational patterns are used to create objectsAbstract Factory, Builder, Factory Method, Prototype & Singleton3Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Factories & Their Role in OO DesignIt is important to manage the creation of objectsCode that mixes object creation with the use of objects can become quickly non-cohesiveA system may have to deal with a variety of different contexts with each context requiring a different set of objectsIn design patterns, the context determines which concrete implementations need to be present4Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Factories & Their Role in OO DesignThe code to determine the current context and thus which objects to instantiate can become complexwith many different conditional statementsIf you mix this type of code with the use of the instantiated objects, your code becomes clutteredoften the use scenarios can happen in a few lines of code; if combined with creational code, the operational code gets buried behind the creational code5Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Factories provide CohesionThe use of factories can address these issuesThe conditional code can be hidden within thempass in the parameters associated with the current contextand get back the objects you need for the situationThen use those objects to get your work doneFactories concern themselves just with creation letting your code focus on other things6Wednesday, April 13, 2011© Kenneth M. Anderson, 2011The Object Creation/Management RuleThis discussion brings us to this general design ruleAn object should either make and/or manage other objectsORit should use other objectsBUTit should never do both7Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Discussion (I)This rule is a guideline not an absoluteThe latter is too difficult; think of iOS view controllersThey exist to create a view and then respond to requests related to that view (which may involve making queries on the view)This violates the rule, strictly speaking, as it both creates AND uses its associated viewBut it is primarily a creational pattern within iOS8Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Discussion (II)But as a guideline, the rule is usefulLook for ways to separate out the creation of objects from the code that make use of those objectsencapsulate the creation process and you can change it as needed without impacting the code that then uses those objectsThe book demonstrates the advantages of the rule with the following two diagrams 9Wednesday, April 13, 2011© Kenneth M. Anderson, 2011The perspective of a client object10Client ObjectInterface or Abstract ClassConcrete Class AConcrete Class BClient knows about this classClient knows nothing about these classesThe client is completely shielded from the concrete classes and only changes if the abstract interface changesWednesday, April 13, 2011© Kenneth M. Anderson, 2011The perspective of a factory object11Factory ObjectInterface or Abstract ClassConcrete Class AConcrete Class BFactory knows the name of this class but not how to use itFactory knows how and when to create instances of these classes «references»«creates»«creates»The factory knows nothing about how to use the abstract interface; it just creates the objects that implement itWednesday, April 13, 2011© Kenneth M. Anderson, 2011Factories help to limit change12If a change request relates to the creation of an object, the change will likely occur in a factoryall client code will remain unaffectedIf a change request does not relate to the creation of objects, the change will likely occur in the use of an object or the features it providesyour factories can be ignored as you work to implement the changeWednesday, April 13, 2011© Kenneth M. Anderson, 2011Abstract Factory and Factory MethodWe’ve already seen several factor y patternsFactory Method: Pizza and Pizza Store exampleHave client code use an abstract method that returns a needed instance of an interfaceHave a subclass implementation determine the concrete implementation that is returnedAbstract Factory: Pizza Ingredients ExamplePattern that creates groups of related objects13Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Singleton PatternUsed to ensure that only one instance of a particular class ever gets created and that there is just one (global) way to gain access to that instanceLet’s derive this pattern by starting with a class that has no restrictions on who can create it14Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Deriving Singleton (I)public class Ball {private String color;public Ball(String color) { this.color = color; }public void bounce() { System.out.println(“boing!”); }}Ball b1 = new Ball(“red”); Ball b2 = new Ball(“green”);b1.bounce(); b2.bounce();15Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Problem: Universal InstantiationAs long as a client object “knows about” the name of the class Ball, it can create instances of BallBall b1 = new Ball(“orange”);This is because the constructor is public. We can stop unauthorized creation of Ball instances by making the constructor private16Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Deriving Singleton (II)public class Ball {private String color;private Ball(String color) { this.color = color; }public void bounce() { System.out.println(“boing!”); }}// next line now impossible by any method outside of BallBall b1 = new Ball(“red”);17Wednesday, April 13, 2011© Kenneth M. Anderson, 2011Problem: No Point of Access!Now that the constructor is private, no class can gain access to instances of BallBut our requirements were that there would be at least one way to get access to an instance of BallWe need a method to return an instance of BallBut since there is no way to get access to an instance of Ball, the method