GoF Patterns – Ch 23

GoF Patterns – Ch 23 • GoF (Gang of Four): Gamma, Johnson, Helm & Vlissides • Book: • Design Patterns: Elements of Reusable Object-Oriented Software • 1995 91.3913 R McFadyen

Factory Pattern • Factory (23.3) • Problem: who should be responsible for creating objects when there are special considerations such complex creational logic, … • Solution: create a Pure Fabrication object called a Factory that handles the creation 91.3913 R McFadyen

Factory Pattern • Textbook example • The NextGen POS system supports several kinds of 3rd party services. For example: tax calculators such as TaxMaster and Good As Gold, account packages such as SAP and Great Northern. The support is provided through “adapters”. • The concern here is the choice of class to create the required adapters. • Choosing a class in the domain model will lower the cohesion of that class. • Applying the Factory Pattern, we would then have a Factory object that is given the responsibility to create such adapter objects. 91.3913 R McFadyen

SingletonPattern • Singleton (23.4) • Problem: Exactly one instance of a certain object is required (this object is called a singleton). Ensure a class has only one instance. (Factories and Facades are usually singletons). • Solution: use a static method of the class to return the singleton 91.3913 R McFadyen

SingletonPattern • Singleton (23.4) • In Java, you would have code such as: • Public static synchronized ServicesFactory getInstance() • { • If (instance == null) • Instance := new ServicesFactory() • Return instance • } The point of the above is that only one instance is ever created. If one already exists, then the create is bypassed and the reference to the existing object is returned. 91.3913 R McFadyen

SingletonPattern Collaboration diagram: suppose an instance of the ServicesFactory is created and, later on, a message is passed to this instance. (Note: on page 350 the text makes reference to the situation illustrated below as “uninteresting”) :Register ServicesFactory getInstance() create() :ServicesFactory msgx() 91.3913 R McFadyen

SingletonPattern Figure 23.6 By applying the <<singleton>> stereotype to this object, they are implying that the getInstance method was used to instantiate it. <<Singleton>> :ServicesFactory :Register getAccountingAdapter() create() :AccountingAdapter msgy() 91.3913 R McFadyen

SingletonPattern The text makes reference to Lazy Instantiation – The ServicesFactory object was created when it was needed, and not before <<Singleton>> :ServicesFactory :Register getAccountingAdapter() create() :AccountingAdapter doIt() 91.3913 R McFadyen

GoF Patterns – Ch 23