1 / 49

Design Patterns

Design Patterns. David Talby. This Lecture. Patterns for a User Interface Representing a Document Composite, Flyweight, Decorator Writing Portable Code Abstract Factory, Singleton, Bridge Undo, Macros and Versions Command. A Word Processor.

thompsonmark
Download Presentation

Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Patterns David Talby

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

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

  4. A Data Structure • 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; }

  5. Composite Documents

  6. At Runtime • Unlimited Hierarchy problem solved • Dynamic selection of composites • Open for additions

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

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

  9. The Solution • Extrinsic state = worth sharing • Intrinsic state = not worth sharing

  10. The Solution II • 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 }

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

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

  13. The UML

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

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

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

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

  18. The Solution • 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; }

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

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

  21. The UML

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

  23. Known Uses • Embellishing Document • Background, Border, Note, ... • Communication Streams • Encrypted, Buffered, Compressed

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

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

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

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

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

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

  30. The Solution • Separate the two hierarchies:

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

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

  33. The GoF UML

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

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

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

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

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

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

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

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

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

  43. The Solution • A macro is a Composite Command • if, for, while are Decorator Commands

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

  45. The Solution • Each MenuItem or ToolbarItemrefers to its command object • Just as it refers to an image • The command can be configured • Less command classes • Macros fit in the picture as well!

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

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

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

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

More Related