Design Patterns

1. Don’t reinvent the wheel Design Patterns

2. The Design Patterns Book

3. Design Patterns • “simple and elegant solutions to specific problems in object-oriented software design” • If there are “tried and true” approaches that have worked on similar problems in the past, you can benefit by adopting them. • Design patterns can enhance the vocabulary of design • The people you are talking to have to know the names and meanings of the patterns

4. Patterns are Reusable Solutions • Each pattern has • A pattern name • Naming the pattern provides powerful short-hand for design solutions • A problem description • The problem in general terms • A solution • Describes the design • A set of consequences • Trade-offs involved in applying the pattern

5. Singleton • Intent: • Ensure a class only has one instance, and provide a global point of access to it. • Motivation • It’s important for some classes to have exactly one instance. • We often need global access to just objects • Applicability • Exactly one instance of a class must be accessible to clients from a well-known access point • The sole instance should be extensible by subclassing

6. Implementation in C++ • Static Singleton* Instance(); • Instance does one of the following • Creates an instance of the class and returns it, storing the value as a static private data member • Returns a previously created instance • Protected Singleton constructor • External code cannot create an instance of the singleton class

7. Singleton Example • SpriteLand • Design Patterns uses Instance() • We use getSpriteLand() • Look at SpriteLand implementation

8. Inheritance versus Composition • Object Inheritance (is a) • Whitebox reuse • Internals of parent class often visible • Breaks encapsulation • Can’t change at runtime • Non-abstract base classes define part of physical representation • Directly supported by language (polymorphism) • Easy to modify an existing implementation • Object Composition (has a) • Blackbox reuse • Internals of delegate class not visible • Can change at runtime (limited by base class data type) • Fewer implementation dependencies • Smaller hierarchies

9. Prefer Composition to Inheritance • Delegation • A object contains a delegate object • Requests to the object are explicitly referred to the delegate, similarly to how a subclass implicitly refers functions that have not been overridden to its parent class. • Disadvantage • Dynamic, parameterized software is harder to understand

10. Strategy (or Policy) Pattern • Intent – Define a family of algorithms, encapsulate each one, and make them interchangeable. • class Tower • { • public: • void setShootingStrategy(ShootingStrategy* newStrategy) { shootingStrategy = newStrategy;} • Target* findTarget() { shootingStrategy_->findTarget; }; • private: ShootingStrategy* shootingStrategy_; • };

11. Creational Patterns • Factory • Abstract Factory • Builder • Prototype • Singleton

12. Factory Method (Virtual Constructor) • Define an interface for creating an object, but let subclasses decide which class to instantiate. • class TowerDefenseGame • { • // Factory methods • virtual Path* makePath(); • virtual Tower* makeMonkeyTower(); • } • // The TowerDefenseGame can be subclassed to //EasyTowerDefenseGame and DifficultTowerDefenseGame • makePath() and makeMonkeyTower() are overridden so that EasyTowerDefenseGame::makePath() returns an instance of class EasyPath, and DifficultTowerDefenseGame::makePath() return an instance of class DifficultPath.

13. Abstract Factory (or Kit)(Factory that uses delegation rather than inheritance) • Provide an interface for creating families of related or dependent objects without specifying their concrete classes. • class ComponentFactory • { • Path* makePath(); • Tower* makeMonkeyTower(); • }; • class TowerDefense • { • public: • Path* makePath() { componentFactory->makePath(); } • private: • ComponentFactory* componentFactory_; • };

14. Prototype • Specify the kinds of objects to create using a prototypical instance, and create new objects by copying the prototype. • class TowerDefenseGame • { • public: • TowerDefenseGame(Path* prototypePath, • Tower* prototypeMonkeyTower) : prototypePath_(prototypePath), prototypeTower_(prototypeTower) {} • Path* makePath() { return prototypePath_.clone(); } • Tower* makeMonkeyTower() { return prototypeTower_.clone(); } • private: • Path* prototypePath_; • Tower* prototypeTower_; • }

15. Structural Design Patterns • How classes and objects are composed to form larger structures • Structural class patterns use inheritance • Structural object patterns use composition

16. Adapter (aka Wrapper) • Convert the interface of a class into another interface clients expect. • Can use multiple inheritance • Structural class pattern • Can use composition • Structural object pattern

17. Bridge (aka Handle/Body aka PIMPL) • Decouple an abstraction from its implementation so that the two can vary independently. • C++ • Pointer to implementation • class myClass • { • public: • // Define public interface private: myClassImpl* implementation; • };

18. Uses for Bridge • Completely divorce public interface from implementation. (C++ headers) • Allow different implementations to be assigned at runtime. • You want to share an implementation between multiple objects

19. Some Sample Patterns (from the Design Patterns Book) • Singleton • Ensure a class only has one instance, and provide a global point of access to it. • Factory Method • Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. • Bridge • Decouple an abstraction from its implementation so that the two can vary independently • Façade • Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

20. Composite • Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. • Problem – We want to build composite objects from primitive objects, and then use the composites as though they are primitives. • Abstract base class represents both primitives and their containers. • Windows Forms use this pattern. • Windows have components that can also be windows • Messages sent to windows are forwarded to their components.

21. Decorator • Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. • Decorators are implemented as classes that contain an instance (component) of the thing that they are decorating • Example • Window contained in a ScrollingDecorator which in turn is contained in a BorderDecorator. Window requests are routed first to the outer-most decorator and forward to inner decorators until finally reaching the window.

22. Decorator Implementation • Decorator must conform to interface of decorated component. • Decorators should be light-weight (focus on interface, not data storage). • Change the skin of an object rather than change the guts.

23. Facade • Provide a unified interface to a set of interfaces in a subsystem • Provide a single-point of contact between subsystems • Provide a task-oriented interface to a set of components (compile, rather than scan, parse, generate code, optimize, etc). • Decouple dependencies between components and component clients.

24. Flyweight • Use sharing to support large numbers of fine-grained objects efficiently • Flyweight is a shared object that can be used in multiple contexts simultaneously • Intrinsic state • What is stored inside the flyweight • Independent of flyweight’s context • Extrinsic state • Client objects track the extrinsic state and pass it to member functions that need it. • Example • Flyweight for each letter in a text document • Position and typographic style are extrinsic state

25. Flyweight Applicability • Application uses a large number of objects • Most object state can be extrinsic • Many instances can make use of a shared object.

26. Proxy • Provide a surrogate or placeholder for another object to control access to it. • Uses • An expensive class can be replaced by a proxy until it must be created • Control access based on a set of access rights • Smart pointers!

27. Behavioral Patterns • Behavioral class patterns • Use inheritance • Behavioral object patterns • Use composition

28. Chain of Responsibility • Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. • Each object, starting with the first in in a chain of objects, get a chance to handle the request, or pass it along the chain. • Example • Windows

29. Command • Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue, or log requests, and support undoable operations. • Use when you want to build an object that invokes a command (like a UI button), and you don’t want to tie a button press to a hard-coded function. • Delegates in C# come to mind • Execute() can store state to provide an Unexecute() function.

30. Iterator (aka Cursor) • Provide a way to access the elements of an aggregate (collection) object sequentially without exposing its underlying representation. • Support variation in traversal method • Preorder, postorder, inorder tree traversal • Simplify the interface • Use of multiple iterators allows us to keep track of multiple places in the aggregate.

31. Mediator • Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. • Each object knows only of the Mediator • Reduce coupling between components • Mediator must know objects and interactions • Centralizes control • Simplifies object protocols

32. Memento (aka Token) • Without violating encapsulation, capture and externalize an object’s internal state. • Often used to restore state via undo operations • Originator (the class whose state will be saved as a memento) supports the methods • CreateMemento() // Create a memento with state • SetMemento(Memento m) // Restore state • Mementos are opaque objects that are used only for setMemento operations

33. Observer (aka publish-subscribe) • Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. • Example: • Spreadsheet data used to generate a grid-view of the data and several different types of data • When the underlying data changes, all presentations must be updated. • The “Subject” knows its observers • Subject notifies each observer of change • Upon notification, observers request data from subject • In Model/View/Controller pattern, model is subject, views are observers.

34. State • Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. • Abstract “State” class contains a pointer to concrete state classes that to whom all requests are delegated. • Example: • Person class might be implemented as an abstract state where • Sleeping • Working • Playing provide concrete implementations of “answerPhone()”