02 - Creational Design Patterns

1. 02 - Creational Design Patterns Moshe Fresko Bar-Ilan University תשס"ח 2008

2. Design Patterns • Design Patterns help you learn from others’ successes, instead of your failures • Separate things that change, from the things that doesn’t change • Elegant and Cheap-to-Maintain • Three classes of DPs • Creational • Behavioral • Structural

3. Creational Design Patterns • Creational DP: • Abstracts the instantiation process. • Help make a system independent of how objects are created, composed, represented. • Two types of Creational Patterns • Class creational patternsUse inheritance to vary the class that is instantiated • Object creational patternsDelegates instantiation to another object

4. Creational Design Patterns • Two recurring themes in these patterns • They encapsulate knowledge about which concrete classes the system use. • They hide how instances of these classes are created and put together. • The system only knows the interfaces. • Creational DP-s let you configure the system with “product” objects • Configuration can be static (compile-time) or dynamic (run-time).

5. Example: To build a Maze

6. Maze Example – MapSite Abstract class enum Direction { North, South, East, West } ; class MapSite { public: void Enter() = 0 ; } ;

7. Maze Example – Room class Room: public MapSite { public: Room(int roomNo); { roomNumber = number ; } MapSite* GetSide(Direction d) const { return sides[d] ; } void SetSide(Direction d, MapSite* m) { sides[d] = m ; } virtual void Enter() { /* … do something … */ } private: MapSite* sides[4] ; int roomNumber ; } ;

8. Maze Example – Wall and Door class Wall: public MapSite { public: Wall() ; virtual void Enter() ; } ; class Door: public MapSite { public: Door(Room*=0, Room*=0) ; virtual void Enter() ; Room* OtherSideFrom(Room*); private: Room* room1 ; Room* room2 ; bool isOpen; } ;

9. Maze Example – Collection of Rooms class Maze { public: Maze() ; void addRoom(Room r) ; Room* RoomNo(int) const; private: // … };

10. Maze Example – Creation of Maze class MazeGame {public: Maze* CreateMaze() { Maze* maze = new Maze() ; Room* room1 = new Room(1) ; Room* room2 = new Room(2) ; Door* door = new Door(room1,room2) ; maze->AddRoom(room1) ; maze->AddRoom(room2) ; room1->SetSide(North, new Wall()) ; room1->SetSide(East , door) ; room1->SetSide(South, new Wall()) ; room1->SetSide(West , new Wall()) ; room2->SetSide(North, new Wall()) ; room2->SetSide(East , new Wall()) ; room2->SetSide(South, new Wall()) ; room2->SetSide(West , door) ; return maze ; } } Room 1 Room 2

11. Creational Patterns • Factory Method • Create-Maze calls virtual functions to create components • Abstract Factory • Create-Maze is passed an object to use to create components • Prototype • Create-Maze is parameterized by various prototypes • Builder • Create-Maze is passed an object that can create entire Maze • Singleton • Can ensure that there is only one maze per game.

12. Factory Method Moshe Fresko Bar-Ilan University תשס"ו - 2005-2006 Design Patterns Course

13. Factory Method • Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate. • Motivation: • Example: Framework of Abstract classes • Abstract classes: Document, Application • Application has Open, New, etc. to create new documents • Application cannot know which concrete document to instantiate • Concrete classes: DrawingDocument, DrawingApplication • Factory Method encapsulates the knowledge of which Document subclass to create and move this knowledge out of the framework.

14. Factory Method – Motivation • CreateDocument() is called Factory Method

15. Factory Method – Maze Example class MazeGame { public: virtual Maze* MakeMaze() const { return new Maze() ; } virtual Room* MakeRoom(int n){ return new Room(n) ; } virtual Wall* MakeWall(){ return new Wall() ; } virtual Door* MakeDoor(Room* r1, Room* r2) { return new Door(r1,r2) ; } Maze* CreateMaze() { Maze* maze = MakeMaze() ; Room* room1 = MakeRoom(1) ; Room* room2 = MakeRoom(2) ; Door* door = MakeDoor(room1,room2) ; ……… ……… return maze ; } } ;

16. Factory Method – Maze, Customized Components class BombedWall: public Wall { // … } ; class RoomWithABomb: public Room { public: RoomWithABomb(int n) : Room(n) { } } ; class BombedMazeGame: public MazeGame { public: BombedMazeGame(); virtual Wall* MakeWall() { return new BombedWall() ; } virtual Room* MakeRoom(int n) { return new RoomWithABomb(n) ; } } ;

17. Factory Method – Applicability • Use the Factory Method when • A class can’t anticipate the class of objects it must create • A class wants its subclasses to specify the objects it creates • Classes delegate responsibility to one of several helper subclasses and you want to localize the knowledge of which helper subclass is the delegate

18. Factory Method – Structure

19. Factory Method - Participants • Product (Document) • The interface of objects the Factory Method creates • ConcreteProduct (MyDocument) • Implements the product interface • Creator (Application) • Declares the factory method which returns an object of type Product • ConcreteCreator (MyApplication) • Defines the Factory method to returnn an instance of ConcreteProduct

20. Factory Method – Consequences • Eliminates the need to bind application-specific classes into the code. • Disadvantage: Clients might have to subclass the Creator class just to create a particular ConcreteProduct. • Provides hooks for subclasses to create extended version of an object. • Connects parallel class hierarchies.

21. Factory Method – Implementation Issues • Two Major Varieties • Creator class has abstract factory methods • Creator class defines default behavior for factory methods • Parameterized Factory Methods • One factory method can create multiple kinds of products. • All objects must have the same interface. • Factory method can take a class ID. • Language-specific issues. • Creator can keep the Class information for creating new instances, dropping the need for the sub-classing. • Templates can be used to avoid subclassing.

22. Abstract Factory Moshe Fresko Bar-Ilan University תשס"ו - 2005-2006 Design Patterns Course

23. Abstract Factory • Intent: Provides an interface for creating families of related or dependent objects without specifying their concrete classes. • Motivation: • User interface Toolkit supporting multiple look-and- feel standards. (Widgets like Scroll Bars, Windows, Buttons etc.) • Not to hard code these widgets for a particular look-and-feel otherwise hard to change it • We can define a WidgetFactory interface for creating each basic entity • Widget Factory enforces dependencies between the concrete Widget classes

24. Abstract Factory Example

25. Factory Method – Maze Example class MazeFactory { public: Maze* MakeMaze(){ return new Maze() ; } Room* MakeRoom(int n) { return new Room(n) ; } Wall* MakeWall() { return new Wall() ; } Door* MakeDoor(Room r1, Room r2) { return new Door(r1,r2) ; } } ; class MazeGame { public: Maze* CreateMaze(MazeFactory* factory) { Maze* maze = factory->newMaze() ; Room* room1 = factory->newRoom(1) ; Room* room2 = factory->newRoom(2) ; Door* door = factory->newDoor(room1,room2) ; ……… return maze ; } } ;

26. Factory Method – Maze Example class BombedWall: public Wall { // … } ; class RoomWithABomb: public Room { public: RoomWithABomb(int n) : Room(n) { } } ; class BombedMazeFactory: public MazeFactory { public: BombedMazeGame(); virtual Wall* MakeWall() { return new BombedWall() ; } virtual Room* MakeRoom(int n) { return new RoomWithABomb(n) ; } } ;

27. Abstract Factory – Applicability • Use Abstract Factory if • A system must be independent of how its products are created • A system should be configured with one of multiple families of products • A family of related objects must be used together • You want to reveal only interfaces of a family of products and not their implementations

28. Abstract Factory – Structure

29. Abstract Factory – Participants • AbstractFactory (WidgetFactory) • Declares an interface of methods to create abstract product objects • ConcreteFactory (MotifWidgetFactory,…) • Implements the methods to create concrete product objects • AbstractProduct (Window, ScrollBar) • Declares an interface for a product type • ConcreteProduct (MotifWindow, MotifScrollBar) • Defines a product object • Implements the AbstractProduct interface • Client • Uses only interfaces declared by AbstractFactory and AbstractProduct

30. Abstract Factory – Consequences • It isolates concrete classes • It makes exchanging product families easy • It promotes consistency among products • Supporting new kinds of products is difficult

31. Abstract Factory – Implementation • Factory better to be a Singleton • If many product families are possible, the Concrete Factory can be implemented using Prototype. Or alternatively the Class information of products can be kept (for languages supporting Class information). • Defining Extensible Factories: Adding a new Product type means to change AbstractFactory and all its subclasses. A more flexible but less safe design is to add a parameter to operations that create objects.

32. Singleton Moshe Fresko Bar-Ilan University תשס"ו - 2005-2006 Design Patterns Course

33. Singleton • Intent: Ensure that a class has only one instance, and provide a global point of access to it. • Use Singleton • There must be exactly one instance of a class, and it must be accessible to clients from a well known access point. • When this instance should be extensible by sub-classing

34. Singleton • Singleton • Define an Instance operation to access its unique instance. It must be a static method. • Must create its own unique instance.

35. Singleton – Benefits • Controlled access to sole instance • Reduced namespace • May be sub-classed to refine operations • Can Permit a variable number of instances • More flexible than static methods

36. Singleton – Implementation • Ensure a unique instance class Singleton { private: static Singleton* inst = 0 ; protected: Singleton() { } public: static Singleton* getInstance() { if (inst==0) inst = new Singleton() ; return inst ; } } ; • Subclassing the singleton class • How to install the unique instance? • To determine it in getInstance() method • To rewrite getInstance() in the subclass • To keep registry of Singletons

37. Singleton –Maze Factory class MazeFactory { protected: MazeFactory() { } private: static MazeFactory* inst = null ; public: static MazeFactory* getInst() { if (inst==null) inst = new MazeFactory() ; return inst ; } Maze* makeMaze() { return new Maze() ; } Room* makeRoom(int n) { return new Room(n) ; } Wall* makeWall() { return new Wall() ; } Door* makeDoor(Room r1, Room r2) { return new Door(r1,r2) ; } } ;

38. Singleton – Maze Example class MazeGame { public: Maze* createMaze() { Maze maze* = MazeFactory.getInst()->MakeMaze() ; Room room1* = MazeFactory.getInst()->MakeRoom(1) ; Room room2* = MazeFactory.getInst()->MakeRoom(2) ; Door door* = MazeFactory.getInst()->MakeDoor(room1,room2) ; maze->AddRoom(room1) ; maze->AddRoom(room2) ; ……… return maze ; } }

39. Singleton – Alternative Maze Factory MazeFactory* MazeFactory::getInst() { if (inst==0) { const char* style = getenv("MAZESTYLE") ; if (strcmp(style,"BOMBED“)) inst = new BombedMazeFactory() ; else if (strcmp(style,"BOMBED“)) inst = new EnchantedMazeFactory() ; else inst = new MazeFactory() ; } return inst ; }

40. Template Singleton Class // in .h template <class T> class Singleton : public T { public: static Singleton* GetInstance() { if (! ptrSingObject) ptrSingObject = new Singleton ; return ptrSingObject ; } ~Singleton() { delete ptrSingObject ; } private: Singleton() { } ; static Singleton* ptrSingObject ; }; // In .cpp template <class T> Singleton<T>* Singleton<T>::ptrSingObject = NULL ; // usage class CMyClass { void myfunc() ; } ; // In the program to use Singleton<CMyClass>::GetInstance()->myfunc() ;