Factory, Singleton & Strategy All References and Material From: Applying UML and Patterns, 3 rd ed, chpt 26 & 13 BTS530: Major Project Planning and Design

Agenda Factory Singleton Strategy

Problem Who creates the adapters (and other similar classes)? If domain object does then we have cohesion (and coupling) issues—the responsibilities are going beyond pure application logic. E.g. If Register creates an instance of SAPAccountingAdapter then its cohesion is lowered=>not acceptable!

Solution: Factory Pattern A Pure Fabrication “factory” object is defined to create objects. Advantages responsibility of complex creation is separated into cohesive helper objects potentially complex creation logic is hidden allows introduction of memory management strategies such as object recycling (for performance enhancement)

Fig. 26.1

Fig The decision of which class to instantiate is made by reading in the class name. What pattern does this follow? (No source code change is required to FactoryServices class for new adapter classes)

Singleton The ServicesFactory class is an example of the Singleton Pattern, which allows exactly one instance of a class. =>Objects need a global and single point of access. =>Define a static method of the class that returns the Singleton.

Fig. 26.6

Singleton Since visibility to public classes is global (most languages), in any part of code, in any method of any class: SingletonClass.getInstance() in order to obtain visibility and send it a message.

public class Register { public void initialize() …blah blah do some work //accessing the singleton Factory via the getInstance call accountingAdapter = ServicesFactory.getInstance().getAccountingAdapter(); …blah blah do some more work } // other methods } // end of class

DBFacade as Singleton

Credit Authorization Example

Scenario: request credit approval from CIBC visa creditAuthAdapter=CreditAuthFactory.getInstance().getCreditAuthAdapter()

We know the following from the previous diagrams:

Points formula Example This is an example of a STRATEGY pattern – the sorting algorithms are interchangeable via a common interface

//Choose which points formula to use System.setProperty("pointsFormulaName","apps.custPoints.PctFormula"); If we were using the “percentage” points formula then somewhere in our startup code we would have the following:

Scenario: Add more points ptsFormula = FormulaFactory.getInstance().getPointsFormula(); return(ptsFormula.convertToPoints(val));

We know the following from the previous diagrams:

Strategy Problem How do you design for related but varying algorithms/policies AND for the ability to change them?

Strategy A Suggestion/Solution Define each algorithm/policy/strategy in a separate class, with a common interface.