Upload
easter-gaines
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
Design Patterns A "hot topic" in O-O research Started by the book Design Patterns:
Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides (the Gang of Four).
The idea: some useful patterns of objects and associations recur in lots of places. So, find the "best" patterns, and encourage their use.
"Best'' usually means elegant, efficient, reusable, flexible.
Design Patterns The idea of formalizing recurring patterns
has origins in architecture; see A Pattern Language by Alexander, Ishikawa, Silverstein, Jacobson, Fiksdahl-King and Angel.
“Each design pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”
Reasons to use It is much easier to explain the code to
someone else We obtain an immediate toolbox for solving
any problem put in front of us: when confronted with a programming problem, we can think along the way “what design pattern is appropriate here?”
Even none of the known patterns are appropriate, examinations of the problem through the lens of design patterns will help us have a better understanding of the problem
Design pattern: common ones
The design patterns can be generally categorized into three types: Creational patterns Structural patterns Behavioral patterns
Design patterns: Creational Virtual copy constructor The use of “clone” in polymorphism The factory: To allow us to have an object
that spits out objects when we need them (create objects of the relevant type)
Singleton: One way to implement the factory. The feature is that there is a single copy of the object which is accessible from everywhere, without introducing global variables and all the difficulties they imply
Design pattern: Structural Adapter: The adapter is a class that translates an
interface into a form that other classes expect. It is most useful when we wish to fit code into a structure for which it was not originally designed, either because we have changed our way of doing things or because the code originates elsewhere
Bridge: The bridge defines an interface, and acts as an intermediary between a client class and the classes implementing the interface
Decorator: The decorator allows to change the behavior of a class at run-time without changing its interface. We can decorate as many time as we like because decoration does not change the interface
Design patterns: Behavioral Strategy: We defer an important part of algorithm
to an inputted object. This allows us to easily change how this particular part behaves
Template: Rather than inputting an aspect of the algorithm, we defer part of the algorithm’s implementation to an inherited class. The base class only provides the structure of how the different parts of the algorithm fits together, it does not specify all the implementations
Iterator: Iterator is one of the most important component of the standard library. The algorithms in STL are performed over iterators.
Example Pattern Name: Adaptor Intent: Convert the interface of a class into
another interface clients expect. Adaptor lets classes work together that couldn't otherwise because of incompatible interfaces.
Motivation: Sometimes a toolkit class that's designed for reuse isn't reusable only because its interface doesn't match the domain-specific interface an application requires.
Example 1 Suppose we have a linked list class:
Now we need a stack. We can adapt the linked list class to a
stack by renaming the methods.
Example 1 (cont.)It's code looks like: class linkedStack : private linkedList {public:
linkedStack() {length = 0;}void push(char c) {prepend(c); length++;}char pop() {length--; return del(); }int size() {return length;}bool isEmpty() {return (length == 0);}char top() {return first();}void reset() {release(); length = 0;}
private:int length;
};
Example 2 A drawing editor letting users draw and
arrange graphical elements (lines, polygons, text, etc.) into pictures and diagrams.
There is a Shape class, and many subclasses. The LineShape and CircleShape and so forth
are easy, but a TextShape is quite difficult. There is a TextView class in the toolkit, but
its interface is quite different than that of Shape.
Solution: Define TextShape that adapts the TextView interface to the Shape interface.
Consequences
The object adaptor Lets a single Adaptor work with
many Adaptees---that is, the Adaptee itself and all its subclasses (if any).
Makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making Adaptor refer to the subclass rather than the Adaptee itself.
Example 2: Pricing Exotic Options with MC Implement the pricing of path-
dependent exotic options (by using Monte-Carlo simulation). Summarize the statistics obtained from the pricing procedure
To be specific, price the Asian Options Use design patterns to solve this
programming problem
Example 2: Identify components
There are four distinct actions we need to price the path-dependent exotic options: The generation of the stock price path The generation of the cash-flows given a stock price path The discounting and summing of cash-flows for a given path The averaging of the prices over all the paths a summarization of the statistics
Example 2: Encapsulation We must encapsulate these actions into different
objects (classes), and this is one of the most important step in OOP design
For 1, we need to design a “path generator” class For 2, since it is about the type of the path-
dependent option, we should design a “PathDependent” class
For 1, 2, and 3, they should be all encapsulated in a class that price the exotic options. Name this class “ExoticEngine”
For 4, we need to design a “statistics collector” class to do the average and record the statistics
Example 2: Communications Path generator gets the times of the spot prices required form the
PathDependent product and then generate a vector of spot values The ExoticEngine gets information about the possible cash-flow
times from the PahtDependent product, it will use this information to compute the discounted factors and reserve a vector to store the cash-flows
The ExoticEngine gets the vector of spot values from the Path generator
The Exotic Engine passes the vector of spot values to the PathDependent product, which passes back the number of cash-flows, and puts their values into the vector previously reserved
The ExoticEngine discounts the cash-flows and sums them up, it then passes the total value to the Statistic collector
The Statistics collector returns the final price and the summary of statistics
Example 2: Design patternsThere are multiple Design Patterns that we can use The implementation of Statistics collector can be realized by using the “Strategy Pattern” The PathDependent class and ExoticEngine class can be implemented by using the “Template Pattern”, because these two classes are the base classes which only define the interfaces. The detailed implementation should be defined later in derived classes We can use the “Bridge Pattern” to deal with the deep copying actions We can use the “Adapter Pattern” to generate a random path from some random number generators We can use the “Decorator Pattern” to realize some complicated implementations based on simple ones and maintain the same interfaces (e.g. Statistical collector)
Example 2: Base classes “RandomBase” class: the path generator “PathDependent” class: the path-dependent option
type “ExoticEngine” class: the exotic option pricing engine “StatisticsMC” class: the statistics collector class
As can be seen, the base classes are all abstract, they only define the interfaces we expect the object to have. The implementations will be defined later in derived classes. Through this ,we can maximize the usage of our codes and make things easy to understand, revise, and maintain
Example 2: Derived class “AntiThetic” class: the path generator with
variance reduction “PathDependentAsian” class: the Asian option “ExoticBSEngine” class: the exotic option
pricing engine in the Black-Schole world “ConvergenceTable” class: the statistic
collector that can returns the convergence rate of the pricing procedure
The detailed implementations are defined in derived classes
A Larger Example: Designing a Document Editor (Read by yourself after class) A WYSIWYG editor called Lexi, similar in
intent to the old MacWrite. Design problems:
Document structure: what is the internal representation? This affects everything else!
Formatting: how does Lexi arrange text and graphics into lines and columns?
Embellishing the user interface: What if we want to add scroll bars, borders, etc.? These might change as the interface evolves.
Design Problems (cont.) Supporting multiple look-and-feel standards:
Motif, Presentation Manager, Mac, Windows… We want independence.
Supporting multiple window systems: MFC or TCL or Borland or…
User operations: Buttons, dialogs, pull-down menus, etc. Provide a uniform mechanism for accessing this scattered functionality, and undoing operations.
Spelling checking and hyphenation: How to support a variety of analytical operations, without having to make changes in lots of places?
Document Structure One perspective: a document is just a
collection of basic graphical elements. User perspective: the physical structure
of lines, columns, figures, tables, etc. The user wants to manipulate this
physical structure directly, through Lexi's interface, e.g., it should be possible to move an entire table, not just the individual lines and characters.
Internal Representation Choose an internal representation that
matches the document's physical structure.
It should support maintaining the physical structure (the
arrangement of lines into columns, etc.) generating and presenting the document
visually mapping positions on the display to elements
in the internal representation.
Constraints Text and graphics should be treated
uniformly, so one set of operations works for both.
The internal representation shouldn't have to distinguish between a single element and a group of elements, so arbitrarily complex structures can be built.
It should be possible to distinguish types of elements; hyphenating a polygon makes no sense.
Glyphs Glyphs have three basic
responsibilities. They know how to draw themselves, what space they occupy, and their children and parent.
This example shows the Composite pattern.
Glyph OperationsResponsibility Operations
appearance virtual void Draw(Window)virtual void Bounds(Rect)
hit detection virtual bool Intersects(const Point)
structure virtual void Insert(Glyph, int)virtual void Remove(Glyph)virtual Glyph Child(int)virtual Glyph Parent()
Formatting The Glyph arrangement gives a representation
of the document's physical structure. But how to determine that structure? Determining the structure is Lexi's job; the user
expects line breaking to happen for free. How will a formatting algorithm be applied to the
data structure? Formatting algorithms come in many flavors, but
they are mostly all complex. How to keep multiple algorithms encapsulated, and separate from the document structure?
Can we change the algorithm at run-time?
Strategy Pattern A solution is to provide a
Compositor class, having subclasses for the various formatting algorithms.
Then, a new Glyph subclass called Composition is added.
Composition/Compositor A Composition object gets an instance
of a Compositor subclass when it's created, and it tells the compositor to Compose its glyphs when something changes (user adds new glyphs, reformats, etc.).
Responsibility Operations
what to format void SetComposition(Composition)
when to format virtual void Compose()
Unformatted Composition An unformatted Composition
contains only the visible glyphs (the document's basic content, no line breaks).
This probably should never be visible!
Embellishing the User Interface Suppose we want to be able to add a
border, and scroll bars (and maybe more).
One way: create subclasses of the Composition class. How many might we end up with? BorderedComposition, ScrollableComposition, BorderedScrollableComposition, etc.
Embellishments (cont.) Maybe object composition is a
better way. Suppose we make another class called Border.
But does Glyph contain Border, or does Border contain Glyph?
The latter requires no change in Glyph.
Embellishments (cont.) Borders have appearance, so they are a
kind of Glyph. Also, clients shouldn't care whether
glyphs have borders or not. When clients tell a plain, unbordered
glyph to draw itself, it should do so without embellishment.
If that glyph is in a border, the client shouldn't have to do anything differently.
Embellishments (cont.) So, make Border a subclass of Glyph. This is the idea of a transparent
enclosure. This combines single-child composition and compatible interfaces. Clients can't tell if they're dealing with the component or its enclosure.
Declare a subclass of Glyph called MonoGlyph as an abstract class for ``embellishment glyphs.''
Transparency
MonoGlyph stores a reference to a component and forwards all requests to it. So by default MonoGlyph is transparent to its user.
void MonoGlyph::Draw(Window w) { _component.Draw(w);} At least one operation of the subclass extends the forwarded behavior: void Border::Draw(Window w) { MonoGlyph::Draw(w); DrawBorder(w);}
Multiple Embellishments To get just a border around a composition, create the composition, then ``wrap it'' in a Border, and then draw it: Window w = new Window;Composition comp = new Composition;Border bordComp = new Border(comp);bordComp.Draw(w); To make a bordered, scrollable composition, just repeat the pattern: Window w = new Window;Composition comp = new Composition;Border bordComp = new Border(comp);Scroller scrBordComp = new Scroller(bordComp);scrBordComp.Draw(w);
Supporting Multiple Look-and-Feel Standards Can Lexi be easily retargeted to a different
interface standard? Think Motif, X, Windows, Presentation Manager, and so on.
Suppose we have GIU libraries for each standard.
Suppose they all support the same “widgets,” that is, dialogs, buttons, scrollbars and so forth.
We don't want hard-coded instances likeScrollBar sb = new MotifScrollBar;
We might forget to change one, and end up with a Motif menu a Mac application!
Try ThisscrollBar * sb = new guiFactory->createScrollBar;
where guiFactory is an instance of a MotifFactory class. CreateScrollBar returns a new instance of the proper ScrollBar subclass for the look and feel desired.
Abstract Factory Pattern For clients, the effect is the same as
asking for a MotifScrollBar, but Motif isn't mentioned by name.
How to make this work? We'll use an abstract class GUIFactory,
that has methods like CreateScrollBar and CreateButton.
Subclasses implement these operations to return glyphs such as MotifScrollBar or PMScrollBar.
Getting That Look If it's clear at compile time what
the look and feel will be, then write GUIFactory * guiFactory = new
MotifFactory;
Or Do It At StartupGUIFactory * guiFactory;const char styleName = getenv("LOOK_AND_FEEL");
if (strcmp(styleName,"Motif") == 0) { guiFactory = new MotifFactory;} else if (strcmp(styleName, "Presentation_Manager") == 0) {
guiFactory = new PMFactory;}
User Operations Some of Lexi's functionality is through the
WYSIWYG representation (enter/delete text, select ranges, etc.).
Other functionality is accessed through menus, buttons and keyboard accelerators. Things like create a new document open, save, print a document cutting and pasting changing fonts and styles changing formatting (alignment, justification) quitting
User Operations (cont.) There may be multiple ways of accessing
these features, for instance from the menu, or by using an accelerator, or clicking a toolbar tool.
These operations are implemented in many different classes (so let's try to reduce dependencies). We also want undo and redo.
The solution is to encapsulate requests. A pull-down menu is just another kind of
glyph, but one that does something in response to a mouse-up event.
The Solution Make MenuItem a subclass of Glyph, with the
ability to do some work in response to a request from a client (probably an event dispatcher).
One approach: make a subclass of MenuItem for each operation. But we don't make a glyph subclass for every letter, so this seems wrong.
Besides, we don't want to repeat the code in multiple places (for a menu item, a accelerator, a tool).
So, encapsulate the command, then attach it to the menu item.
Undoability Some commands should be reversible. The command for changing a font could
store the range of text and the old font.
Some commands should be reversible, but others not.
So add a Reversible() method to Command that returns a Boolean.
Undoability Lexi can keep track of a command history,
perhaps a doubly-linked list, like this:
past commands present
Each circle is a command object. Then undo and redo simply march along the command history.
Spell Check and Hyphenation Once again several algorithms are
available, with time/space/quality tradeoffs. There are other operations that we’d like to
apply to the whole document, or to part (searching, word counting, complexity analysis, etc.).
But the Glyph class shouldn’t have to change when a new capability is added.
Two problems: Accessing the information, and doing the analysis.
Accessing the Information In accessing information, different
Glyphs may store their children in different data structures.
Also, we may need to search in reverse order.
Currently, a Glyph uses an integer to locate its children.
We can improve this:
Accessing the Informationvoid First(Traversal kind)
void Next()
bool IsDone()
Glyph GetCurrent()
void Insert(Glyph)
The type Traversal is an enumeration,
with values such as PREORDER and REVERSE.
Drawbacks This approach isn’t very good, because
it’s difficult to add new traversal strategies.
Putting this code in the Glyph classes would force us to constantly rewrite Glyph.
Once again, encapsulate the concept that varies, this time by introducing iterators.
Iterator Pattern
ArrayIterator
currentItem
First( )Next( )IsDone( )CurrentItem( )
Glyph
...( )CreateIterator( *
PreorderIterator
First( )Next( )IsDone( )CurrentItem( )
Iterator
First( )Next( )IsDone( )CurrentItem( )
*
*
root
iterators
*
Iterators We can add new types of traversals
without modifying the glyph classes. Iterators store their own copy of the
state of traversal, we can have multiple traversals going simultaneously.
We could also parameterize iterators, so they would apply to other classes as well.
Traversals vs. Traversal Actions Where should the responsibility for
actions be? In the iterator itself? No! Different analyses require the same
type of iterator. We could put specific functions likeCheckMe(SpellingChecker checker)
in each glyph, but “that would be wrong.”
Better to use the Visitor pattern.