Don’t reinvent the wheel. The Design Patterns Book.
-
Upload
bryan-cook -
Category
Documents
-
view
235 -
download
16
Transcript of Don’t reinvent the wheel. The Design Patterns Book.
DESIGN PATTERNSDon’t reinvent the wheel
The Design Patterns Book
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
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
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
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
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
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
Singleton Example
SpriteLand Design Patterns uses Instance()
We use getSpriteLand() Look at SpriteLand implementation
Multithreading Considerations for Singleton from “Head First Design Patterns”
Need some synchronization to prevent the creation of multiple instances Use “synchronized” keyword for Java
constructor private static synchronized Singleton getInstance()
Create the single instance before any calls to the singleton class private static Singleton instance_ = new Singleton();
Use “double-checked locking” If (instance_ == null)
Synchronized (Singleton.class) { if (instance_ == null) {
uniqueInstance = new Singleton();
Consider needs for mutual exclusion in other singleton methods. Remember, access to data member
in the singleton are shared and might require synchronization.
Creational Patterns
Factory Abstract Factory Builder Prototype Singleton
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.
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() = 0; Tower* makeMonkeyTower() = 0; }; class TowerDefense { public: Path* makePath() { componentFactory-
>makePath(); } private:
ComponentFactory* componentFactory_;
};
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_; }
Structural Design Patterns How classes and objects are
composed to form larger structures Structural class patterns use inheritance
Structural object patterns use composition
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
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;
};
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
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.
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.
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.
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.
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.
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
Flyweight Applicability
Application uses a large number of objects
Most object state can be extrinsic Many instances can make use of a
shared object.
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!
Behavioral Patterns
Behavioral class patterns Use inheritance
Behavioral object patterns Use composition
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
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.
Iterator (aka Curso)
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.
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
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
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.
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()”