Factories, Builders and Singletons. Steven R. Bagley

Transcription

1 Factories, Builders and Singletons Steven R. Bagley

2 The Patterns So Far Behavioural Patterns Strategy Observer Structural Patterns Decorator

3 Introduction Object Creational Patterns Sometimes new isn t enough

4 new Object The new operator creates a new object of a particular class CFoo *pfoo = new CFoo(); Type of object fixed at compile time No way to change the type at run time Tied to a concrete implementation

5 Object Creation Interfaces let our code use objects without knowing what they are But to create objects they must know about concrete types Object creational patterns are about letting code create objects without knowing their concrete type

6 Object Creation Families of related objects e.g. UI toolkits All support a common interface Multiple implementations for different environments However code that uses them has to know about all types to create the correct type Patterns to abstract it away

7 Complex Objects Creation of objects can be complicated Decorator pattern for instance Might be produced based on input from a file (e.g. parsing an XML document)

8 How many? new can create multiple instances of a class Sometimes necessary to restrict the number of instances E.g. object represents a specific resource of which there is only one

9 Object Creation Object Creational Patterns Factory Singletons Builder

10 new not harmful These patterns augment new Don t replace it All the patterns will call new at some point Sometimes it makes sense to call new Other times it makes sense to abstract it

11 Diagrams Suppose we want to output diagrams from our application Model these diagrams internally as objects Objects represent common features (lines, rectangles, circles etc). Serialize the objects into the image format (e.g. PDF)

12 Diagram AddShape Serialize 1 * <<interface>> Shape SetPosition SetFill SetStroke Serialize Rectangle Text BezierCurve

13 void DrawDiagram() Diagram *diag = new Diagram(); Shape *tmp; tmp = new Rectangle(300,300); tmp->setposition(72,72); diag->addshape(tmp); tmp = new Text( Hello World, ); tmp->setposition(36,40); diag->addshape(tmp); /* */ diag->serialize( new.pdf );

14 Fixed Format Code fixed to PDF format To change the format, we need to change the code Change diagram objects to export another format Change generation code to create new objects

15 Late-bound Diagrams Output format decision made at runtime Interfaces for the objects (Diagram, Rectangle etc) Concrete Implementations for each format

16 <<interface>> Diagram AddShape Serialize <<interface>> Shape SetPosition SetFill SetStroke Serialize PDFDiagram SVGDiagram Rectangle Text BezierCurve PSDiagram PDFRectangle PSRectangle PDF BezierCurve PS BezierCurve SVGRectangle PDFText PSText SVG BezierCurve SVGText

17 Confusing code Implementing support for multiple formats is easy Using it however is not Every time we need to create an object, we need to check what type we should use

18 Diagram diag; switch(output) case SVG: diag = new SVGDiagram; break; case PSCRIPT: diag = new PSDiagram; break; default: diag = new PDFDiagram; break;

19 Encapsulate Code That s a lot of code to write every time Why not encapsulate it? Create a new class with methods to create each type of object Rather than create the objects directly call the methods on an instance of this class

20 class DiagramFactory public: DiagramFactory(int type); Diagram *CreateDiagram(); Rectangle *CreateRectangle( ); Text *CreateText( ); Bezier *CreateBezier( ); private: int m_output; ;

21 void DrawDiagram(DiagramFactory *f) Diagram diag = f->creatediagram(); Shape tmp; tmp = f->createrectangle(300,300); tmp->setposition(72,72); diag->addshape(tmp); tmp = f->createtext( Hello World, ); tmp->setposition(36,40); diag->addshape(tmp); /* */ diag->serialize( new.pdf );

22 Diagram *DiagramFactory::CreateDiagram() switch(m_output) case SVG: return new SVGDiagram; break; case PSCRIPT: return new PSDiagram; break; default: return new PDFDiagram; break;

23 Rectangle *DiagramFactory::CreateRectangle(int width, int height) switch(m_output) case SVG: return new SVGRectangle(width, height); break; case PSCRIPT: return new PSRectangle(width, height); break; default: return new PDFRectangle(width, height); break;

24 Proto-Factory Almost a Factory Our code is now completely isolated from any concrete objects Factory is a bit messy Lots of duplicated code checking which type of object to create Type fixed when factory created

25 Abstract Factory Abstract Factory pattern Define the Factory as an abstract interface Inherit from that concrete implementations for PDF, PostScript and SVG

26 <<interface>> DiagramFactory CreateDiagram CreateRectangle CreateText CreateBezierCurve PDFDiagramFactory PSDiagramFactory SVGDiagramFactory

27 Diagram *SVGDiagramFactory::CreateDiagram() return new SVGDiagram; Diagram *PDFDiagramFactory::CreateDiagram() return new PDFDiagram; Diagram *PSDiagramFactory::CreateDiagram() return new PSDiagram;

28 void DrawDiagram(DiagramFactory *f) Diagram diag = f->creatediagram(); Shape tmp; tmp = f->createrectangle(300,300); tmp->setposition(72,72); diag->addshape(tmp); tmp = f->createtext( Hello World, ); tmp->setposition(36,40); diag->addshape(tmp); /* */ diag->serialize( new.pdf );

29 Decisions Removed the conditionals from the code Yet the code still can output to different formats Decision is now in choosing what Factory Object to give DrawDiagram This is classic OO Design

30 Gained Extensibility DrawDiagram can output to any format Providing we have a sub-class of DiagramFactory that lets it create the objects Strive to write code like this!

31 Factory or Strategy? Isn t this just the Strategy pattern? Similar implementation, different reasons Strategy is provides behaviour Abstract Factory is about creating objects So different names

32 <<interface>> AbstractFactory CreateProduct <<interface>> AbstractProduct ConcreteFactory ConcreteProduct

33 Terminology Abstract Factory interface for creating Abstract Products Concrete Factory implements an Abstract Factory to create Concrete Products

34 Terminology Abstract Factory interface for creating Abstract Products Concrete Factory implements an Abstract Factory to create Concrete Products Client uses only Abstract Factory and Abstract Product

35 Other Factory Patterns The Abstract Factory not the only Factory Pattern Abstract Factory most often used when you need to create objects from multiple families of objects E.g. UI objects Used when lots of clients

36 Local Factories Sometimes it is only necessary to vary the objects created in a small context In these cases, creating a Factory Object is over the top Especially if we do not need to vary objects produced at runtime Let s look at another model

37 Pizza Store Imagine modelling the ordering process for an pizza store in OO form Pizzas represented by Objects Pizza objects control production line to create the pizza Base Pizza class with specializations Decorator would allow custom pizzas

38 Pizza Prepare() Bake() Cut() Box() CheesePizza HamPineapplePizza VeggiePizza PepperoniPizza

39 Pizza Store PizzaStore Object to control ordering of pizzas etc Has an OrderPizza method like the following:

40 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; if(0 == strcmp(type, cheese )) pizza = new CheesePizza(); else if(0 == strcmp(type, greek )) pizza = new GreekPizza(); else if(0 == strcmp(type, pepperoni )) pizza = new PepperoniPizza(); continued

41 pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

42 Pizza ordering OrderPizza method creates the correct type of pizza to make Then performs tasks needed to order it Changing supported pizzas means changing OrderPizza Not closed for modification

43 Encapsulation We ve seen this before Encapsulate what varies Take out the creation bit and move it into a PizzaFactory OrderPizza calls the factory s create method to create the relevant pizza

44 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; PizzaFactory *pf = new PizzaFactory; pizza = pf->createpizza(type); pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

45 Different Pizzas By changing the PizzaFactory, we can change the type of pizza Thin-crust Deep-pan So can create franchise stores specializing in different types by changing the factory object the store object uses

46 Quality Control Factory object lets anyone create objects Sometimes necessary to tie the creation into the algorithm more directly A franchise could use our PizzaFactory to implement it s own production line that doesn t use the cut() method

47 Factory Method Make the factory be a method rather than an object A Factory Method Make this method abstract (and private!) Subclass this object to implement factory method

48 Pizza Factory Method In terms of our Pizza Store Add an abstract CreatePizza method Alter OrderPizza to call this method rather than a Factory object

49 class PizzaStore public: Pizza *OrderPizza(char *type); private: virtual Pizza *CreatePizza(char *type) = 0; ;

50 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; pizza = CreatePizza(type); pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

51 Using the PizzaStore Can t create a PizzaStore directly since not all its methods are implemented Need to create concrete subclasses that can be instantiated Subclass for each franchise

52 class NYPizzaStore : PizzaStore private: virtual Pizza *CreatePizza(char *type); ;

53 Pizza *NYPizzaStore::CreatePizza(char *type) Pizza *pizza; if(0 == strcmp(type, cheese )) pizza = new NYStyleCheesePizza(); else if(0 == strcmp(type, greek )) pizza = new NYStyleGreekPizza(); else if(0 == strcmp(type, pepperoni )) pizza = new NYStylePepperoniPizza(); return pizza;

54 class ChicagoPizzaStore : PizzaStore private: virtual Pizza *CreatePizza(char *type); ;

55 Pizza *ChicagoPizzaStore::CreatePizza(char *type) Pizza *pizza; if(0 == strcmp(type, cheese )) pizza = new ChicagoStyleCheesePizza(); else if(0 == strcmp(type, greek )) pizza = new ChicagoStyleGreekPizza(); else if(0 == strcmp(type, pepperoni )) pizza = new ChicagoStylePepperoniPizza(); return pizza;

56 How it works Create an instance of a franchise (e.g. NYPizzaStore) Call OrderPizza on this instance Implementation of OrderPizza from baseclass is called

57 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; pizza = CreatePizza(type); pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

58 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; pizza = CreatePizza(type); pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

59 Pizza *NYPizzaStore::CreatePizza(char *type) Pizza *pizza; if(0 == strcmp(type, cheese )) pizza = new NYStyleCheesePizza(); else if(0 == strcmp(type, greek )) pizza = new NYStyleGreekPizza(); else if(0 == strcmp(type, pepperoni )) pizza = new NYStylePepperoniPizza(); return pizza;

60 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; pizza = CreatePizza(type); pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

61 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; pizza = CreatePizza(type); pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

62 Factory Method Definition: The Factory Method defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to the subclasses.

63 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; pizza = CreatePizza(type); pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

64 Design Principle Depend upon abstractions. Do not depend upon concrete classes

65 Dependency Inversion This is the Dependency Inversion Principle Similar to Program to an interface High-level components should not depend on low-level components Both should depend on abstractions

66 Dependency What the heck does this mean? An object depends on something when it relies on it to work This means that object may need to be modified if the thing it depends on changes Look at the original pre-factory Pizza store code

67 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; if(0 == strcmp(type, cheese )) pizza = new CheesePizza(); else if(0 == strcmp(type, greek )) pizza = new GreekPizza(); else if(0 == strcmp(type, pepperoni )) pizza = new PepperoniPizza(); continued

68 Pizza Dependency PizzaStore depends on all the different types of Pizza Even though it uses a Pizza interface It still instantiates the concrete objects So it depends on their implementation E.g. if the constructor changes

69 Pizza Dependency PizzaStore is a high-level component Objects that depend on other objects are called high-level components Their behaviour is defined in terms of other components

70 Pizza *PizzaStore::OrderPizza(char *type) Pizza *pizza; pizza = CreatePizza(type); pizza->prepare(); pizza->bake(); pizza->cut(); pizza->box(); return pizza;

71 PizzaStore high-level component CheesePizza GreekPizza PepperoniPizza low-level components

72 Dependency PizzaStore is a high-level component Pizzas are low-level components PizzaStore depends on concrete Pizzas

73 Independent Pizzastore PizzaStore is written in terms of Pizza interface Because it instantiates the concrete objects directly, it s still dependent on them Factory Method makes PizzaStore independent of the objects It now relies on an abstraction

74 PizzaStore Pizza CheesePizza GreekPizza PepperoniPizza Everything is now dependent on Pizza

75 Dependent Subclasses Because the CreatePizza method isn t implemented PizzaStore is independent of all concrete pizzas We create sub-classes which are dependent on the concrete pizzas

76 Inversion? So where does the inversion bit come in? We invert our way of thinking about the dependency Normally, we think about the high-level components and then the lower level ones it uses Start with abstractions and work out

77 Thinking about Pizza Need to implement a PizzaStore, what do we need? Started at the top and worked down to concrete classes Invert the thinking, start at the bottom and work up Pizza, better have classes for the different types: CheesePizza, VeggiePizza, etc All these pizzas are just pizza, need a Pizza type

78 Inverted Pizzas Thinking about Abstractions, now think about the Pizza store Close, but don t forget to create a factory to create the concrete classes otherwise you are dependent Can design Pizza Store around the abstraction and not worry about the concrete classes

79 Tips for Dependency Inversion No variable should hold a reference to a concrete class No class should derive from a concrete class No method should override an implemented method of any of its base classes

80 Tips for Dependency Inversion No variable should hold a reference to a concrete class No class should derive from a concrete class THESE ARE, No method should override an implemented method of any of its base classes OF COURSE, IMPOSSIBLE!

81 Guidelines The Dependency Inversion Principle is a guideline not a rule Know why you are breaking it If the class isn t likely to change then it isn t a problem (e.g. Java String class) If it is, think careful about whether you d be better to use a Factory Method

82 Which Factory? Factory Method Specializing a class to use a particular set of objects Abstract Factory Change objects created at runtime Lots of users (e.g. UI Toolkit abstraction)

83 Singleton Pattern

84 Controlling Creation By default, object creation is not under the control of the class being created new lets client creates any number of instances But what if we need to restrict the number of objects?

85 Application Preferences Suppose we have an object that handles our application preferences Handles storing them on disk Provides a programatic interface to access the preferences Dangerous to have more than one instance of it

86 Singleton Objects Need to ensure one and only instance is ever created Need to provide a way for the code to find that instance

87 Finding Single instances Global Variables Static Class Variables Forces objects to know about implementation details When does the object get created exactly?

88 Think Factory Factory Methods let us abstract away creation of objects Same technique for handling singletons Usually a static method Clients get the singleton object by calling the method

89 SingletonObject *gpobj = NULL; SingletonObject *GetSingleton() if(null == gpobj) gpobj = new SingletonObject(); return gpobj; Still got a global or static variable to store the pointer to the instance, but the client isn t aware of it

90 Multiple Objects Previous code provides an interface to one and only one instance of a class But clients could still call new to create other instances How do we stop this? Let s look in detail at the constructor

91 class CPotentialSingleton public: CPotentialSingleton(); /* */ ; When we define the constructor we define it as being publically accessible

92 Private Constructors Constructors can be declared public, private or protected Public anything can create them Private only this class can create them Protected only this or subclasses can create them Make the singleton constructor private

93 class CPotentialSingleton private: CPotentialSingleton(); public: /* */ ; Only thing that can create these objects, are other things of the same class

94 Private Construction How do we now instantiate the singleton? Static (class) methods can call private methods on objects Including private constructors If we make GetSingleton() a static method then it can create the single object

95 public GetSingleton method to get the shared instance class CSingleton private: CSingleton(); static CSingleton *s_singleinstance; public: static CSingleton *GetSingleton(); /* */ ; private static variable rather than global now (for neatness mainly) to store instance

96 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance;

97 Singleton Pattern That s the implementation of the singleton pattern Private constructor stops objects instantiated Static method enables the class to control the creation and return of objects

98 Singleton Pattern Definition: The Singleton Pattern ensures a class has only one instance and provides a global point of access to it.

99 Singleton Problem The classic Singleton implementation has a fatal flaw It is not thread-safe It is possible for more than one instance of the singleton to be created Depending on where a context-switch might happen

100 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj

101 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj

102 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj

103 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj

104 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj

105 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj

106 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj someobj

107 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj someobj

108 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj someobj

109 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj someobj

110 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj someobj

111 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj sndobj

112 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) s_singleinstance = new CSingleton(); return s_singleinstance; gpobj sndobj

113 Two Singletons Depending on where context switches occur we can get two singleton objects created The first is a phantom The thread using it will get the second object created next time it calls GetSingleton()

114 Concurrent Singleton Put a lock around the whole code MutEx Use Java s synchronized keyword Concurrency issue only when creating the object So no need to lock when returning the object

115 Better Locking Only get a problem the first time GetSingleton() is called Move to eager object creation (at load time?) Or use finer-grain locking? Finer-grain locks best, but with their own issues

116 Here we lock a mutex while we create the singleton, however we still have the same problem if the context switch happens after the conditional (and before the LOCK happens) How can we get around this? CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) LOCK(someMutex); s_singleinstance = new CSingleton(); UNLOCK(someMutex); return s_singleinstance;

117 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) LOCK(someMutex); if(null == s_singleinstance) s_singleinstance = new CSingleton (); UNLOCK(someMutex); return s_singleinstance; Once we have the lock then we check the variable again, to see if it got changed

118 Double-checked Lock This is called double-checked locking We check the variable to see if we need to get the lock Then we acquire the lock Then we check it again to see if it changed while we tried to get the lock

119 CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) LOCK(someMutex); if(null == s_singleinstance) s_singleinstance = new CSingleton (); UNLOCK(someMutex); return s_singleinstance;

120 Almost there But there is another problems Compilers are too clever by half It assumes that the private static variable cannot be changed between the two conditionals Have to tell the compiler it might change using volatile keyword

121 volatile CSingleton * CSingleton::s_singleInstance = NULL; CSingleton *CSingleton::GetSingleton() if(null == s_singleinstance) LOCK(someMutex); if(null == s_singleinstance) s_singleinstance = new CSingleton(); UNLOCK(someMutex); return s_singleinstance; Finally, a multi-thread safe Singleton implementation

122 Thread-safe Singleton Can t be done in Java less than Java 5, consider other methods Can t be done in C++ at all Because the CPU can reorder the instructions on-the-fly Need to use assembler or external libraries to get around this

123 Bet you didn t think creating an object could be so complicated