Design Patterns David Talby

This Lecture n Patterns for a User Interface u Representing a Document F Composite, Flyweight, Decorator u Writing Portable Code F Abstract Factory, Singleton, Bridge u Undo, Macros and Versions F Command

A Word Processor n Pages, Columns, Lines, Letters, Symbols, Tables, Images,... n Font and style settings per letter n Frames, Shadows, Background, Hyperlink attached to anything n Unlimited hierarchy: Tables with several Paragraphs containing hyper-linked images inside tables n Should be open for additions...

A Data Structure n First, a uniform interface for simple things that live in a document: class Glyph { void draw(Window *w) = 0; void move(double x, double y) = 0; bool intersects(Point *p) = 0; void insert(Glyph *g, int i) = 0; void remove(int i) = 0; Glyph* child(int i) = 0; Glyph* parent() = 0; }

Composite Documents

At Runtime n Unlimited Hierarchy problem solved n Dynamic selection of composites n Open for additions

8. Flyweight n Use sharing to support a large number of small objects efficiently n For example, if every character holds font and style data, a long letter will require huge memory n Even though most letters use the same font and style n How do we make it practical to keep each character as an object?

The Requirements n Reduce the memory demands of having an object per character n Keep the flexibility to customize each character differently

The Solution n Extrinsic state = worth sharing n Intrinsic state = not worth sharing

The Solution II n Put extrinsic state in a class: class CharacterContext { Font* font; bool isItalic, isBold,...; int size; int asciiCode; // many others… draw(int x, int y) {... } // other operational methods }

The Solution III n Original class holds rest of state: class Character : public Glyph { CharacterContext *cc; int x, y; draw() { cc->draw(x,y); }

The Solution IV n A factory manages the shared pool n It adds the object to the pool if it doesn’t exists, and returns it n Here’s Character ’s constructor: Character(int x, int y, Font *f, …) { this->x = x; this->y = y; this->cc = factory.createCharacter(f, …); }

The UML

The Fine Print n There’s a lot of tradeoff in what is defined as “extrinsic” n Shared pool is usually a hash table n Use reference counting to collect unused flyweights n Don’t rely on object identity u Different objects will seem equal

Known Uses n Word processors u Average 1 flyweight per 400 letters n Widgets u All data except location, value n Strategy design pattern n State design pattern

9. Decorator n Attach additional features to an objects dynamically n For example, many features can be added to any glyph in a document u Background, Note, Hyperlink, Shading, Borders, …

The Requirements n We can freely combine features u An image can have a background, a border, a hyper-link and a note n Features are added and removed dynamically n Can’t afford a class per combination n Should be easy to add new features u Don’t put it all in Glyph

The Solution n Meet Decorator, a class for adding responsibilities to another glyph: class Decorator : public Glyph { void draw() { component->draw(); } // same for other features private: Glyph *component; }

The Solution II n Define concrete decorators: class BackgroundDecorator : public Decorator { void draw() { drawBackground(); glyph->draw(); }

The Solution III n Many decorators can be added and removed dynamically: n Behavior can be added before and after calling the component n Efficient in space n Order of decoration can matter

The UML

The Fine Print n The Decorator class can be omitted if there’s only one decorator or Glyph is very simple n The Glyph class should be lightweight and not store data

Known Uses n Embellishing Document u Background, Border, Note,... n Communication Streams u Encrypted, Buffered, Compressed

Data Structure Summary n Patterns work nicely together u Composite, Decorator, Flyweight don’t interfere n Data structures are not layered u Instead, clients work on a Glyph interface hiding structures of unknown, dynamic complexity

Saving and Loading n Java has serialization n Save to disk / Send over network by simply writing the root Glyph object of a document n All optimizations saved as well! n Also works on subtrees n Very little coding n In C++ - best to code read() and write() and work the same way

Cut, Copy, Paste n Cut = Detach a subtree n Copy = Clone a subtree n Paste = Attach a subtree n Also works on composite glyphs n Glyphs should hold a reference to parents for the cut operations n Cloning of a flyweight should only increase its reference count!

10. Bridge n Separate an abstraction from its implementations n For example, a program must run on several platforms n Each platform comes with its own set of GUI classes: WinButton, WinScrollBar, WinWindow MotifButton, MotifScrollBar, MotifWindow pmButton, pmScrollBar, pmWindow

Abstract Factory, Right? n An abstract factory can be used to provide these advantages: u Clients treat widgets uniformly u Easy to add or switch families n However, it requires a class per platform per abstraction:

The Requirements n One class per abstraction, one class per implementation u Basically all platforms give similar functionality for a window u If a platform doesn’t support a feature, we should code it once

The Solution Separate the two hierarchies:

The Solution II n Usually, an implementation inherits the abstraction it implements n The Bridge patterns simply replaces this by composition n This gives several advantages in cases such as the above: u An abstraction can choose its implementation at runtime u Even change implementations

The Solution III u Both the abstractions and the implementations can be extended by subclassing u Changing one does not force recompilation of the other u In C++ this technique completely hides a class’s implementation (its private functions and members) u Many abstractions can share the same implementation

The GoF UML

The Fine Print n Choosing the implementor can still be done with an Abstract Factory n Stateless implementors can be shared (so the Abstract Factory becomes a Flyweight factory)

Known Uses n A program that must run on several platforms n A data structures library u Abstractions: Set, List, Array, Table u Implementations: LinkedList, HashTable, DenseArray, … n Different kinds of images versus algorithms to display them

11. Command n Encapsulate commands as objects n We’ll take the the uses one by one: u Undo/Redo u Macros u Queues and logs u Version control u Crash recovery u Message Grouping

The Requirements I n Undo / redo at unlimited depth n Only store relevant data for undo n Easy to add commands

The Solution n Repesent a command as a class: class Command { public: virtual void execute() = 0; virtual void undo() = 0; }

The Solution II n Concrete commands hold undo data: class DeleteLine : public Command { void execute() { line = document->getLine(); document->removeLine(); } void undo() { document->addLine(line); } private: Line line; }

The Solution III n Keep a list of executed commands: Array commands; int i; n When you click the ‘Undo’ button: commands(i)->undo(); i--; n When you click the ‘Redo’ button: commands(i)->execute(); i++;

The Solution IV n Whenever a command is activated: commands.add(new_command); i = commands.count(); n When you save a document: document->save(); commands.clear(); i = 0; n The commands list may or may not be limited in size n Only relevant undo data is kept

The Requirements II n Macros are a series of commands n Any command with any of its options may be used n There are also for and while loops, if statements, calls to other macros...

The Solution n A macro is a Composite Command n if, for, while are Decorator Commands

The Requirements III n Commands are accessible from menus as well as toolbars n A command may be available from more than one place n We’d like to configure the menus and toolbars at runtime

The Solution n Each MenuItem or ToolbarItem refers to its command object n Just as it refers to an image n The command can be configured u Less command classes n Macros fit in the picture as well!

The Requirements IV n Keep multiple versions of a document n When saving, only store the changes from the previous version

The Solution n The changes are exactly the list of commands since the last version was loaded n In addition, a compaction algorithm is needed for commands that cancel each other n Save = Serialize the compacted list n Load = Read early version and call execute on command lists

(More!) Known Uses n Programs log commands to disk so they can be used in case of a crash u Works, since commands are small u Usually in a background thread n Commands can be grouped and sent as one command to a server u Grouping for efficient communication u Grouping to define a transaction u Works even for user defined macros!

Another Summary n Interfaces rule u As long as Command is abstract, who cares how complex it is n Composition rules u Decorator and Bridge provide flexibility in less written code by avoiding inheritance n Serialization should rule