Design Pattern Catalogues GoF (“the gang of four”) catalogue “Design Patterns: Elements of Reusable Object-Oriented Software,” Gamma, Helm, Johnson, Vlissides, Addison-Wesley, 1995 POSA catalogue Pattern-Oriented Software Architecture, Buschmann, et al.; Wiley, 1996 …

Classification of GoF Design Pattern Creational Structural Behavioral Factory Method Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Flyweight Facade Proxy Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

What are creational patterns? Design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation Make a system independent of the way in which objects are created, composed and represented Recurring themes: Encapsulate knowledge about which concrete classes the system uses (so we can change them easily later) Hide how instances of these classes are created and put together (so we can change it easily later)

Benefits of creational patterns Creational patterns let you program to an interface defined by an abstract class That lets you configure a system with “product” objects that vary widely in structure and functionality Example: GUI systems InterViews GUI class library Multiple look-and-feels Abstract Factories for different screen components

Benefits of creational patterns Generic instantiation – Objects are instantiated without having to identify a specific class type in client code (Abstract Factory, Factory) Simplicity – Make instantiation easier: callers do not have to write long complex code to instantiate and set up an object (Builder, Prototype pattern) Creation constraints – Creational patterns can put bounds on who can create objects, how they are created, and when they are created

Abstract Factory (Creational) Intent Create families of related objects without specifying class names Applicability When clients cannot anticipate groups of classes to instantiate © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

Abstract Factory (Cont'd) Structure «instantiate» «instantiate» © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley «instantiate» «instantiate»

Abstract Factory: Participants AbstractFactory Declares an interface for operations that create abstract products ConcreteFactory Implements the operations to create concrete product objects: usually instantiated as a Singleton AbstractProduct Declares an interface for a type of product object; Concrete Factories produce the concrete products ConcreteProduct Defines a product object to be created by the corresponding concrete factory

Abstract Factory: Applicability Use Abstract Factory when: A system should be independent of how its products are created, composed, and represented A system should be configured with one of multiple families of products You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations

Abstract Factory: Consequences Good: Isolates concrete classes All manipulation on client-side done through abstract interfaces Makes exchanging product families easy Just change the ConcreteFactory Enforces consistency among products Bad Supporting new kinds of products is difficult Have to reprogram Abstract Factory and all subclasses But it’s not so bad in dynamically typed languages

Abstract Factory: Implementation Usually should be a Singleton Define a Factory Method (GoF) in AbstractFactory – ConcreteFactory then specifies its products by overriding the factory for each public class USAddressFactory implements AddressFactory{ public Address createAddress(){ return new USAddress(); } public PhoneNumber createPhoneNumber(){ return new USPhoneNumber(); Maybe use Prototype pattern in dynamically typed languages (e.g. Smalltalk) to simplify creation

Abstract Factory (Cont'd) Consequences Flexibility: removes type dependencies from clients Abstraction: hides product's composition Hard to extend factory interface to create new products Implementation Parameterization as a way of controlling interface size Configuration with Prototypes Known Uses InterViews Kits ET++ WindowSystem

Conclusions Abstract Factory: Lets you choose what family of products to create at runtime Isolates the implementation from clients, since clients only use the interfaces Makes exchanging product families simple

Builder

Builder

Builder

Builder

Builder: Overview Intent Think of a car factory Separate the construction of a complex object from its representation so that the same construction process can create different representations Think of a car factory Boss tells workers (or robots) to build each part of a car Workers build each part and add them to the car being constructed

Builder: Participants Builder Specifies an abstract interface for creating parts of a Product object ConcreteBuilder Constructs and assembles parts of the product by implementing the Builder interface Director Constructs an object using the Builder interface Product Represents the complex object under construction Includes classes that define the constituent parts Gives interfaces for assem- bling the parts Builder: The abstract class of all workers Concrete Builder: A specific worker Director: The boss Product: The car

Builder: Collaborations Client creates Director object and configures it with a Builder Director notifies Builder to build each part of the product Builder handles requests from Director and adds parts to the product Client retrieves product from the Builder

Builder: Applicability Use Builder when: The algorithm for creating a complex object should be independent of the parts that make up the object and how they’re assembled The construction process must allow different representations for the object being constructed The building process can be broken down into discrete steps (difference between Builder and Abstract Factory)

Builder: Consequences Lets you vary a product’s internal representation by using different Builders Isolates code for construction and representation Gives finer-grain control over the construction process

Builder: Implementation Issues to consider: Assembly and construction interface: generality Is an abstract class for all Products necessary? Usually products don’t have a common interface Usually there’s an abstract Builder class that defines an operation for each component that a director may ask it to create. These operations do nothing by default (empty, non-virtual methods in C++) The ConcreteBuilder overrides operations selectively

Conclusions Builder: Lets you vary how a product gets assembled. Can define a new kind of builder for a product to assemble it in a different way Client doesn’t need to know anything about the construction process, nor the parts that make up a product.

FACTORY METHOD (Class Creational) Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

FACTORY METHOD (Class Creational) Motivation: Framework use abstract classes to define and maintain relationships between objects Framework has to create objects as well - must instantiate classes but only knows about abstract classes - which it cannot instantiate Factory method encapsulates knowledge of which subclass to create - moves this knowledge out of the framework

Factory Method Structure ... product = FactoryMethod() return new ConcreteProduct

FACTORY METHOD Motivation docs Document Application Open() Close() Save() Revert() CreateDocument() NewDocument() OpenDocument() Document* doc=CreateDocument(); docs.Add(doc); doc->Open(); MyApplication MyDocument return new MyDocument CreateDocument()

Applicability Use the Factory Method pattern 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.

Participants Product Defines the interface of objects the factory method creates ConcreteProduct Implements the product interface Creator Declares the factory method which returns object of type product May contain a default implementation of the factory method Creator relies on its subclasses to define the factory method so that it returns an instance of the appropriate Concrete Product. ConcreteCreator Overrides factory method to return instance of ConcreteProduct

Factory Pattern Example Car Factory produces different Car objects Original Different classes implement Car interface Directly instantiate car objects Need to modify client to change cars Using pattern Use carFactory class to produce car objects Can change cars by changing carFactory

Factory Example class 350Z implements Car; // fast car class Ram implements Car; // truck class Accord implements Car; // family car Car fast = new 350Z(); // returns fast car public class carFactory { public static Car create(String type) { if (type.equals("fast")) return new 350Z(); if (type.equals("truck")) return new Ram(); else if (type.equals(“family”) return new Accord(); } Car fast = carFactory.create("fast"); // returns fast car

Example Suppose that you are required to develop a system that accepts orders for pizzas. There are three types of pizzas, namely, cheese, Greek, and pepperoni. The pizzas differ according to the dough used, the sauce used and the toppings. Draw a class diagram for the system.

Example:Class Diagram Problems with the design

Example: Revised System Suppose that the Greek pizza is not popular and must be removed and two new pizzas, Clam and Veggie, must be added to the menu. Programming to implementation like makes such changes difficult. Creating a SimpleFactory to encapsulate the code that changes will make the design more flexible. Remove the code that creates a pizza – forms a factory.

Example: Revised Class Diagram

Example: 2nd System Revision Franchises in different parts of the country are now adding their own special touches to the pizza. For example, customers at the franchise in New York like a thin base, with tasty sauce and little cheese. However, customers in Chicago prefer a thick base, rich sauce and a lot of cheese. Some franchises also cut the pizza slices differently (e.g. square) You need to extend the system to cater for this.

Creator Class

Product Class

In Summary The creator gives you an interface for writing objects. The creator specifies the “factory method”, e.g. the createPizza method. Other methods generally included in the creator are methods that operate on the product produced by the creator, e.g. orderPizza. Only subclasses implement the factory method.

In summary (contd.) When you have code that instantiates concrete classes that may change, encapsulate the code that changes. The factory pattern allows you to encapsulate the behaviour of the instantiation. Duplication of code is prevented. Client code is decoupled from actual implementations. Programming to interface not implementation.

Singleton (Creational) Intent Ensure a class only ever has one instance, and provide a global point of access to it. Applicability When there must be exactly one instance of a class, and it must be accessible from a well-known access point When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

Singleton (cont'd) Structure © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

return uniquelnstance static Instance() SingletonOperation() GetSingletonData() Static uniquelnstance singletonData

Singleton Example public class Employee { public static final int ID = 1234; // ID is a singleton } public final class MySingleton { // declare the unique instance of the class private static MySingleton uniq = new MySingleton(); // private constructor only accessed from this class private MySingleton() { … } // return reference to unique instance of class public static MySingleton getInstance() { return uniq;

Singleton (cont'd) Consequences Implementation Reduces namespace pollution Makes it easy to change your mind and allow more than one instance Allow extension by subclassing Same drawbacks of a global if misused Implementation may be less efficient than a global Concurrency pitfalls Implementation Static instance operation Registering the singleton instance © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

Singleton (cont'd) Known Uses Unidraw's Unidraw object Smalltalk-80 ChangeSet, the set of changes to code InterViews Session object © E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

Conclusions Creational design patterns are beneficial in that they allow your software to tightly control the way in which it constructs objects Separate users of the code from the messy details of creating and building objects

Prototype A fully initialized instance to be copied or cloned Definition - Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.

Prototype Pattern

Roles and Responsibilities