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 1. Creational 2. Behavioral 3. 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 1. Class creational patterns Use inheritance to vary the class that is instantiated 2. Object creational patterns Delegates instantiation to another object

4. Creational Design Patterns Two recurring themes in these patterns 1. They encapsulate knowledge about which concrete classes the system use. 2. 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 1Room 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 1. Two Major Varieties Creator class has abstract factory methods Creator class defines default behavior for factory methods 2. 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. 3. Language-specific issues. Creator can keep the Class information for creating new instances, dropping the need for the sub-classing. 4. 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 1. It isolates concrete classes 2. It makes exchanging product families easy 3. It promotes consistency among products 4. 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 Define an Instance operation to access its unique instance. It must be a static method. Must create its own unique instance.

35. Singleton – Benefits 1. Controlled access to sole instance 2. Reduced namespace 3. May be sub-classed to refine operations 4. Can Permit a variable number of instances 5. 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 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 Singleton * Singleton ::ptrSingObject = NULL ; // usage class CMyClass { void myfunc() ; } ; // In the program to use Singleton ::GetInstance()->myfunc() ;