CSE 432 Presentation GoF: Factory Method PH: “To Kill a Singleton”

CSE 432 PresentationGoF: Factory MethodPH: “To Kill a Singleton” Michael Gardner March 20, 2006

Factory Method • Defer instantiation to subclasses • Define interface for creating objects • Subclasses decide which class to instantiate

Applicability • Use 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 to one of several helper subclasses, and you want to localize knowledge about which is the delegate

Participants • Product • Defines interface of objects to be created • ConcreteProduct • Implements Product interface • Creator • Declares factory method • Returns object of type Product • May define default implementation • May call factory method to create Products

Structure

An Example • Application framework • App subclasses “Application,” “Document” • Framework creates Document, hands it to Application • Doesn’t know what type of Document to create • Factory Method moves knowledge about specific Document subclass out of framework

Consequences • Eliminates need to bind creation code to specific subclasses • May need to subclass Creator for each ConcreteProduct • Provides hooks for subclasses • Connects parallel class hierarchies

To Kill a Singleton • GoF makes no mention of Singleton destructors • Who deletes a Singleton?

Who Kills a Singleton? • Could make clients handle deletion • Annoying & error-prone • Dangling references • Since Singleton carries creational responsibility, have it delete as well • Protected destructor (for subclassing)

When do Singletons Die? • Singletons are long-lived • Usually live until program termination • Care about orderly shutown rather than deletion of Singleton instance • 2 alternatives for program-scope Singletons: • Class-static pointer w/ static guard • Destructor implcitly called at program end • Function-static instance

Static Guard: Sample Code static Singleton * instance; static SingletonGuard guard; ... Singleton::getInstance() { if (instance == 0) guard.setSingleton(instance = new Singleton()); return instance; } ... SingletonGuard::setSingleton(Singleton s) { singleton = s; } SingletonGuard::~SingletonGuard() { delete singleton; }

Static Guard: Caveats • Dependent Singletons • Destructor ordering for statics undefined in C++ • Can’t use multiple guards if Singletons’ destructors depend on each other • Use multifunctional guard or atexit()

Function Static Singleton • Make Singleton instance function-static instead of class-static: Singleton & Singleton::getInstance() { static Singleton s; return s; } • Problems: • Hard to extend • Not thread-safe

Singleton Class Templates • Create Singletons by wrapping existing classes in Singleton class template • Problems: • Doesn’t prevent creation of more instances • Compiler issues with class template static data members • Can make existing classes “true” Singletons by subclassing: class User: public Singleton<User> {...};

Summary • Factory Method • Defer object creation to subclasses via “hook” methods and overriding • Creation code need not know about specific subclasses • To Kill a Singleton • Non-public destructor makes Singleton responsible for deletion • Static guard can delete instance implicitly

CSE 432 Presentation GoF: Factory Method PH: “To Kill a Singleton”