Design Pattern and Software Architecture: IV. Design Pattern

Transcription

1 Design Pattern and Software Architecture: IV. Design Pattern AG Softwaretechnik Raum E Tele hg@upb.de IV. Design Pattern IV.1 Introduction IV.2 Example: WYSIWYG Editor Lexi IV.3 Creational Pattern Singleton, Factory Method, Abstract Factory, Prototype IV.4 Structural Pattern Composite, Decorator, Bridge, Adapter IV.5 Behavioural Pattern Observer, Iterator, Strategy, Hook, Template Method, Visitor, Command, Memento IV.6 Discussion & Summary IV.7 Bibliography IV-2 1

2 IV.1 Introduction [Gamma+1994] Design Pattern: Ensure internal software qualities such as changeability at design level (not implementation!) Classification: Creational Patterns Structural Patterns Behavioural Patterns IV-3 IV.2 Example Design of a WYSIWYG Editor Lexi [Gamma+1994] Design Aspects: 1. Document structure 2. Text formatting, search for regular expressions, line breaking, spell checking 3. Global state system root, selection, zooming, User Interface 5. Different Look-And-Feels 6. Different Window systems 7. Undo/Redo, Macros,... IV-4 2

3 Coarse Grain Design Software Architecture IV-5 Internal Representation? IV-6 3

4 Tree Structure of What? IV-7 Concept of A Glyph Use basic OO: Use subtyping (not inheritance) to handle each specific glyph in a uniform manner Use shared aggregation or composition to describe composition structure IV-8 4

5 Text Formatting, Searching, Line Breaking, Spell Checking, <<creates>> <<creates>> <<creates>> <<creates>> <<creates>> IV-9 Manage Aspect using different Tools for Line Breaking, IV-10 5

6 Manage GUI Elements? IV-11 Support Multiple Window Systems IV-12 6

7 Support Undo/Redo IV-13 IV.3 Creational Pattern Motivation: abstract from instantiation process Make system independent of object creation [Gamma+1994] Basic Themes: Encapsulate knowledge about concrete classes Hide how objects are created and composed Details: What class? Who creates? How? When? Problems: Class creation spread over the code (no single point of change) Patterns: Singleton Factory Method Abstract Factory Prototype IV-14 7

8 Design Pattern Singleton Lexi system root: Exactly one root object Reachable from everywhere Support for dynamic subtyping [Gamma+1994] IV-15 Factory Method Pattern [Gamma+1994] Intent: Dynamic choice of the underlying class when creating the object Problem: Direct object creation via x = new C () creates exactly one object of fixed type C (no flexible choice supported) Solution: Encapsulate object creation in method Redefine method in subclasses Distinguish cases using parameters, options, environment Related Patterns: Often realized using the Prototype Pattern; see also Abstract Factory Pattern IV-16 8

9 Example: Document Creation IV-17 Abstract Factory Pattern Intent: Groups factory methods and structures creation of related objects Problem: How to manage the creation of families of related or dependent objects [Gamma+1994] Solution: Encapsulate their object creation within one class Redefine in subclasses as required Related Patterns: Often realized using the Factory Methods Pattern Often a concrete Factory is also a Singleton IV-18 9

10 Example: GUI Factory Abstract Factory with Factory Methods ensures type secure programs IV-19 Prototype Pattern [Gamma+1994] Intent: Reduce complex initialisation and constructor processing and instead clone an exist instance Problem: Initialisation of complex objects is often time consuming and required behaviour is not related to a new class but rather the composition of given classes (Java Swing) Related Patterns: An Abstract Factory might use a set of prototype to clone instead of create the required instances Design with the Composite and Decorator Pattern can often benefit from Prototype as well IV-20 10

11 Prototype Pattern Intent: Reduce complex initialisation and constructor processing and instead clone an exist instance Example: Extend Lexi with a Tool-Palette for a sheet of music IV-21 Example: Prototype & Cloning IV-22 11

12 " Example: Creational Patterns More flexible (GUI Factory does not know all widget types at compile-time) Abstract Factory with Prototypes required run-time type checks Often mixed forms IV-23 Dynamic Cast Pattern Problem: Type casts vs. secure static types that ensure correct usage of operation class etc. Language Solution: run-time test for casts (Exceptions) Limitation: Attempt to cast non-glyph to Composite is not detected at compile-time (only runtime error) Solution: Declare all valid casts in Glyph using to_composite Trade-off:! Superclass requires cast-op for all subclasses Somtimes multi level casts required IV-24 12

13 -. ' ( ) * + IV.4 Structural Pattern Motivation: # Compose objects to realize new functionality $ Flexible structures that can be changed at run-time Problems: % Fixed class for every composition is required at compile-time otherwise Patterns: & Composite Pattern Decorator Pattern Bridge Pattern Adapter Pattern Facade Pattern Flyweight Pattern [Gamma+1994] IV-25 Composite Pattern Intent: Compose objects into a tree to represent part-whole hierarchies where the composition and its parts are treated uniformly Related Patterns, Often the Decorator Pattern is used combined with the Composite Pattern. The Iterator Pattern can be used to traverse composite structures. The Visitor pattern can be used to localize behaviour that would otherwise be distributed across the composites and leafs. IV-26 13

14 Composite Pattern Example Support a tree (DAG) of similar/uniform treated objects (Example: Lexi document structure) Advantages: / Uniform simply extendable structure 0 Implicit operation forwarding 1 Simple recursive traversing Naïve OO solution: 2 Many classes 3 Many casts IV-27 Composite Pattern Realization IV-28 14

15 : = > ; < Composite Pattern Realization Idea: 4 Common abstract superclass (Glyph) determines ALL essential properties For application this rather abstract superclass is often enough Composite forwards his operations to all children => Apply operations uniformly on (sub-)trees Implementation: 7 Explicit parent reference? => Better use association instead of simple reference Sharing components? Later => Design Pattern Flyweigth Maximizing base-class interface? Yes! - subclasses may inherit useless methods + more uniform classes prevent casts Where are the child managing operations Add and Remove declared? Composite => type safe, but contradicts "maximizing base-class interface" Component => not type safe because leafs will never contain other composites Child ordering? Often yes! Who should delete components? Composition or Shared Aggregation? Often Composition! IV-29 Implementation Variant 1 Efficient Variant:? Distinguish char from the rest Clean Keep uniform treatment IV-30 15

16 B C G Decorator Pattern Intent: Attach additional functionality to objects and not classes dynamically Alternative to subclassing! Also Known As: wrapper Related Pattern: A Adapter change interface degenerated form of Composite that adds responsibilities change skin rather than internals such as Strategy IV-31 Decorator Pattern Example Example: D Add Frames, Scroll Bars, Borders, Background, Shadows, etc. to the document root Basic OO: E Redefine method Problem: F Not flexible Add/Remove "Decorators Leads to complex case statements IV-32 16

17 I L Decorator Pattern Realization Idea: H Use explicit Decoration objects Dynamic changes possible Design Goal: J "seamless" decoration => Standard: K Forward most operations Decorate some operations and add functionality and status where required IV-33 Decorator Pattern Realization IV-34 17

18 N P R S T U Bridge Pattern Intent: Decouple abstraction and implementation of class hierarchies Also Known As: Handle/Body Motivation: M Hierarchy of classes with similar functionality Achieve platform independence using abstract superclasses and platform specific subclasses Explosion of the class hierarchy Related Patterns: O An Abstract Factory may create and configure a Bridge While a Bridge is designed up-front an Adapter might be used in already existing systems IV-35 Bridge Pattern Example Design Aspects: Q "double dispatch : the kind of window and its specific implementation determines the finally called operation Flexible separation of interface objects and implementation objects Implementation can be exchanged without recompilation => shared libraries WindowImp interface is sufficient for all specific kind of windows WindowImp subclasses often adapter for the related basic libraries IV-36 18

19 X Y Bridge Pattern Realization IV-37 Adapter Pattern Intent: Adapt extern interfaces (libraries, modules,...) to the required internal interfaces Also Known As: Wrapper Example: V Type conversions for parameters Related Pattern: W The Bridge is used to separate the interface form its implementation while the adapter is used to change the interface to an existing object Proxies are representatives for other objects, but do not change the interface Decorator keeps the interface and adjusts functionality while the Adapter adjust the interfacse and keeps the functionality IV-38 19

20 \ ] ^ Adapter Pattern Realization IV-39 Facade Pattern Intent: Provide a unified interface to a set of interfaces in a subsystem Motivation: Z Support subsystem encapsulation using a single explicit interface object Related Patterns: [ An Abstract Factory may provide an interface for creating objects in a subsystem independent way An Abstract Factory can be used as alternative by hiding subsystem specific classes A Mediator has similar functionality, but has two combined systems and does not abstract form one of them Often Facade objects are also Singletons IV-40 20

21 a e Flyweight Pattern Intent: Use object sharing to support huge numbers of fine-grained objects efficiently Motivation: _ Benefit from using objects also where their unshared usage would be prohibitively expensive Related Patterns: ` Often combined with Composite State and Strategy objects are often Flyweights IV-41 Flyweight Pattern Example Problem: Number of character objects becomes a problem when for each character font attributes etc. have to be stored composite (row) composite (column) composite (row) Intrinsic state: b Independent of context Extrinsic state: c Varies with the context Example: d Character (intrinsic) Font, location (extrinsic) composite (row) a p p a r e n t composite (column) composite (row) a p p a r e n t a e n p r t z IV-42 21

22 p f g h i j k l m n IV.5 Behavioural Pattern Motivation: Assign responsibilities between objects to realize algorithms and behaviour Problem: How to distribute behaviour between different classes Patterns: Strategy Pattern Template Method Iterator Pattern Visitor Pattern Command Pattern Memento Pattern Hook Pattern [Gamma+1994] IV-43 Strategy Pattern Intent: Encapsulation of a family of dynamically interchangeable algorithms Also Known As: Policy Problem: o Best" algorithm can often not uniquely determined due to trade-offs: Run-time <-> Memory, Run-time <-> Quality Best solution depends on problem characteristics: e.g. for sorting: data structure, stability, problem size,... Related Pattern: q Strategy objects often make good flyweights [Gamma+1994] IV-44 22

23 s t u v w x Strategy Pattern Example Formatter: r quick&dirty slow&fine (TeX) IV-45 Strategy Pattern Realization Idea: explicit algorithm object Abstract algorithm superclass "Delegation" dynamically assign what algorithm should be used IV-46 23

24 z } ± ² ³ µ Strategy Pattern Realization Key Issue: Strategy / Context Interface Strategy knows" Context structure: y Strategy has reference of Context/Document Context provides fat" interface => tight Context/Strategy coupling Context propagation via parameter: { Context provides ALL required information to the Strategy: loosely coupling Problem: TEXFormatter requires more details than Simpleformatter! => always provide MAXIMAL information ~ ƒ ˆ Š Œ Ž ƒ Œ ƒ š š Œ œ žÿƒ œš Š Œ Ž ƒ Š Œ Ž ƒ ~ ƒ ˆ Š Œ Ž ª «ª ŠŠ Ÿ ž ƒ See also: Visitor Design Pattern IV-47 Strategy Pattern Realization Pros: Families of algorithms An alternative to subclassing Strategies eliminate conditional (switch) statements (dynamic) choice of implementation Cons: Delegation => communication overhead IV-48 24

25 Template Method Pattern Intent: Define a skeleton algorithm with steps deferred to subclasses Example: Sort algorithm parameterised with iterator, less-op, swapop Related Pattern: Factory Methods are often called by Template Methods Template Methods use inheritance to vary parts of the algorithm while Strategy use delegation to vary the entire algorithm [Gamma+1994] IV-49 Template Method Example IV-50 25

26 Á Â Ã Å Æ Ç È º» ¼ ¾ Template Method Realization Design aspects: ¹ An OO classics! Reuse superclass with extensive implementation Simple application/context specific subclasses define the details in deferred operations Extract common code/functionality into superclass Implementation: ½ Access control: deferred operations have to be protected Minimizing the number of required deferred operations Naming Convention: name deferred operations doxxx IV-51 Iterator Pattern (Problem) Problem: Permit access to aggregated set of elements Why not use Arrays? À Arrays provide no encapsulation => no information hiding => reduced changeability Invariants, e.g. ordered, can not be ensured due to arbitrary access Static size => often to many memory is allocated (can not grow) Insert is inefficient (when a new memory chunk has to be allocated) Solution: Container classes generalize and replace arrays Ä Hierarchy of containers for different tasks: Lists, Sets, Bags, Stacks, Vectors, Heap, Trees, Graphs, Maps,... Independent of entry type: Container<ValueType> Example: stack<string> s; s.push( Karl ); cout << s.top( ); s.pop( );... Use Iterator to access Container: Provide sequential access to all elements Support multiple clients in parallel Uniform access operations => exchangeability IV-52 26

27 ! " ä ö # $ % & How To Encapsulate A Container? Via values: É Ê Ë ÌÎÍÐÏ Ñ Ì Ò ÓŒÔÕÏ ËˆÖ ÓÙØ ÚÜÛ ÝŠÌ ÞàßáÌ â ÞáÒ â Øàã Inefficient: O(log(n)) or O(n) Use index (Array): å æ ç åéè ê ë ì íîîðï ð íîñ ò í îôó å õàè Local Cursor: No extern navigation and instead locally stored position Õø ùõúõûüúšýÿþ û üú Õø ù û û Õø ùõúõûüúáû fits only to arrays, but not linked lists. The support for random" access restricts the choice of possible implementations to a great extent Encapsulation Not "reentrant" IV-53 How Encapsulate a Container? Extern cursor: specific record/class that contains index Iterator: like Cursor, but navigation is done using only the Iterator cursor := c.first (); cursor2 = c.first (); c.next (cursor); c.islast (cursor); c.remove (cursor); Uniform due to abstract superclass container All functionality is located in the container, cursor encapsulates only the position Suitable solution, but not used! iter = c.start (); x = iter.get(); iter.next(); iter.atend (); Very uniform access operations (Hierarchies of Iterators) Configure Iterator: iter = tree.start (postorder); Easy to use on client side Functionality distributed on Container and Iterator THE Standard!! IV-54 27

28 ) * + -. Iterator Pattern Intent: Provide a way to access aggregated elements sequentially without exposing the underlying representation Motivation: ' Permit access to aggregated element set directly (parameter or access) breaks encapsulation [Gamma+1994] Related Patterns: ( Often applied to recursive structures such as Composites Polymorphic Iterators via Factory Methods Memento can be used to store Iterator position IV-55 Cursor vs. Iterator? Similar for the client, but in libraries most often Iterator, e.g., O2, Leda, STL... IMPORTANT:, Container are available and therefore should be reused Container are used like elements of the programming language itself Set, list, stack are not modelled explicitly any more and instead their implementation is implicitly assumed when associations with multiplicity 0..* are used for (Cursor i = userlist.start ();!userlist.atend (i); userlist.advance (i) ) { user = userlist.get (i); } for (Iterator i = userlist.start ();! i.atend (); i.advance () ) { user = i.get (); } IV-56 28

29 / Iterator & Composite Structures Intent: Uniform treatment for document structur (vgl. JGL) Motivation: JGL-conform Iterator for composite- /document structur Enable general access strategies (e.g., JGL algorithm foreach, find,... ) Hierarchies of alternative traversals: PLR (Parent-Left-Right), LRP, LR,... Also for subtrees Any start node Example: :6;< =>@?BAC@?ED FG7?IH JLK?LM JLC@?ON9@H JLK?6D P@Q R S6Q RTGU V Q R SWH VWX < >@?BAC@?IU :67?LYOKTGQ RX ZB[ \OC@C J U T@K J X ZBU :67? ]ER SX ZB[ R K ^_H A F6M?BMTG?LM : ;6]GR SX Z Z ` IV-57 Complex Iterator Example acb deegf b h i j kch dj l hkmj kcn oeqprb sutvi j k h dj l h w th x ycdj kqpqb sutvojlv kprb sctvz t{ b x agf b h i j k h dj l h } pqb sctvdp~b sutv w j v k prb sut v gdp~b sutvz ƒ t{ b x a~pqb sutvq kjl} wwh kj {h n j v kpqb sctvz ƒ t{ b x aqdo ycdcn akg} w j vx eol n kgx eool n k jlh sg l j l x h ê j acvx b o kcb ekq l j lge x b x n x } j v kprb sut v c gn{b bi j vh l n k Š {n j x Œqk mcak t j x l n} Ž t dejjlv kkcn ož6 z x } jlv kprb sctv k x n O Gvx b o h k n8} L dˆj n o} w j v k prb sut v 8} prb sutv j v kpqb sut v k x n ~ Gvx b o h kcn} kj@} z x h ej a vx b o ƒ@k b e kow kˆj x b x n x h ej@{tg{n jlx b n l j b dej a vx b o p~b sutv j v kcfd h kcn j j v kpqb sutcv kjlfdch kcn j } Lz l h }z j v k fdch kcn j@ n{b } j v k fdch kcn j kcn o ~ Wvx b o h kcn} L kˆj@} qj v kpqb stvz w jlv kp~b sutv Oj v kcf dch k n j z j v kcf dch k n j qj v kpqb sut v kˆj fdch kcn j@} Lzqƒ x } j v kcfdch kcn j 8n{b bw j v k prb sut v gn{b b z ƒ@k b e kow x n oœos ekcb x nga vcx b o8b x ej dcn oacv lcle kgn kmj kcb kcœ kcn j i nt { j i j kch dj l h x j k h g x n o } j v kcf dch kcn k x n O Gvx b o h kcn} j v kcf dch k n j kcn o ~ Wvx b o h kcn} jlv k pqb sutvolz x j kch do ycdcn a kg} z j v k prb sut v 8x j kch kj@} z ƒ IV-58 29

30 š Design of Complex Iterators Options: Iterator construction with plrbegin is possible for all glyphs: + Recursion is addressed uniform for user - Find sibling inefficient ( linear search in liste => O( n/2 ) ) Solutions: 1. Iterator only for document (subtree): use stack of Iterators (see [Gamma+1994] Chapter 2.8) 2. Glyph stores in addition to theparent his position (myposinchildren) 3. Mixed Forms: Maintain stack of Iterators when go down For Sibling the stack is used when possible, otherwise inefficient search is used IV-59 Iterator & Strategy Realization Ÿœ ~ B qÿ «ª 6œ œ W «ª ± Eœ ª²6 B³O 6 µ ²6 B B O ¹ºœ O ¹ºª 6œ œ Ÿ Ÿ6»LẂ I ¼Gœ L½ B Ǵ 6ª«²@ ³O 6 µ ž œ O ² 6 ¾ L µ G ÀÁ L µà  Gà œ ž6ÿ Iµ ²6 ~ B»G L»~»W Gà 6 L Ä ª µ ²6 LÅ Æ µ ²@ ÇÈ»~ 6 L É œ u «6à œ O ¹ºªÀ Ê B O ¹ œ O ¹8Ë œ q L qÿ L 6ª œ O ¹Ìµ ž œ O ² 6 6 ª± L Lµ ²6 E Í»~ ¾ Î Ǵ ÀG qÿ G µ ²@ qÿ u O œ q L qÿ «ª Í Ï IV-60 30

31 Ñ Ò Ó Ô Õ Visitor Pattern (Problem) Problem: Ð For classes A { public m()... } and class B extends A { public m( )... } we want that depending on the runtime typ of x either x.m () is A::m or B::m() => called operation depends on runtime type of an object ("single dispatch ) Sometimes even "double dispatch is required when called operation depends on multiple runtime types Example: Lexi tools such as SpellChecker, Hyphenator, Formatter,... and Glyph classes Within the Strategy-Pattern, for example, the Glyph operation getchar is required: aglyph.do (atool) charglyph + spellchecker => SpellChecker::checkChar (charglyph) rowglyph + formatter => formatrowbegin (rowglyph) (Language construct for "double dispatch" (see CLOS language) solves problem!!) IV-61 Visitor Pattern Intent: Perform a specific operation when traversing the elements of an object structure Example: Compiler with abstract syntax tree and type-checking, code generation, Idea: Achieve the required double dispatch using two single dispatch calls and explicit visitor objects! Related Pattern: Ö Traversal using Composite Use to realize Interpreter [Gamma+1994] IV-62 31

32 Ø Ù Ú Û Ü Ý Þ ß à â ã Visitor Pattern Realization IV-63 Visitor Pattern Implementation Design Aspects: Main advantage: getc (or similar access operations) are not further an element of the Glyph Elegant cooperation between two class hierarchies Separation in data structures, traversal and algorithms New Visitors can be easily added Hosts are not required to be of related types Visitor algorithm objects can accumulate State Traversal Algortihm: Object structure (Composite) Iterator Visitor itself Problems: á New Glyph classes are expensive (all Visitors have be adjusted) Guidelines: The class hierarchy with less classes and changes should be the hosts The more complex and less frequent changing hierarchy should be the Visitors => In our example its better to chose the Glyphs as "Visitors IV-64 32

33 Command Pattern (Problem) Problem: ä The common technique to use a switch covering all Menu-Items or Buttons results in fixed assignment of user interface elements and functionality. This often lead to multiple implementations of functionality and hindrance to adjust the user interface. Also Undo and Macro mechanism are difficult to provide. Idea: å Use explicit command objects that enable more flexible management æçgèé ê ëíì~î8ê ïñðeòqð~ëóiêlôoõë~öñï«îqøgù ú úlú ûwüíê õërýñóbëröþï î øgù ú ú ú ë~ÿoû~ð ûeõêlô ˆôñÿ~û ûoðó ø! " îërçqöþðrôrõgõˆý ð " îëñôqðeü " îgëqçqöñðqôoõ ó ôoø# $ îîqõ&% êlôoïîqü ú ðgõó ø ú ægçoõ " îgëqçgöþðrôrõ ó õýqð " îgëeø! è'ð~ÿ' ë~ÿoû~ð ()*+, ú ú ú ë~ÿoû~ð.-,,/ / í 0, IV-65 Command Pattern Intent: Encapsulate Requests in explicit objects allowing undo and macro support Also Known As: Action, Transaction [Gamma+1994] Motivation: Permit flexible composition of window widgets with required functionality Related Pattern: 1 Use a Command as a Prototype for a history list 2 Use a Memento to remember class specific state IV-66 33

34 : ; Command Pattern Realization Attach Widgets such as Buttons or MenuItems with commands that are executed when selected! Hierarchy of commands to organize stuff IV-67 Command Pattern Implementation Design Aspects: 3 Connection MenuItem <-> Command often dictated by GUI- Builder Connection Command <-> document / data structure: 5 Document is parameter fir Command construktor Access via Singleton (see Lexi) Command-Schnittstelle: 8 exec, undo, redo (history can be managed in Command::exec too) beginofparams,... Operations to request extern parameters Abbrev. Such as geticon, isexecutable, help,... are used for the dynamic construction of Menus ) parse, unparse operations support for scripting interfaces (Macros) IV-68 34

35 < = Idea for Undo/Redo Support Store executed commands to enable undo and redo steps Stored command elements have to additionally remember their subject of change (e.g., cut requires text fragment and position) Sequence of command elements represents the past, present and future IV-69 Undo/Redo Realization Use ordered association of commands with undo / redo operations to maintain a history Make History object a Singleton IV-70 35

36 B C D H I F G Undo/Redo Implementation Alternatives: A Single-level (multi-level) Undo (History has maximal 1 (n) entries) (linear) Undo/Redo (alternatives: see Ipsen/Progres-Modell): newcmd.exec () after an undo results in erasing future command => no further support for redo reflexive Undo: add Undo to History: Undo( Undo ) = Redo (see Emacs) => Redo contra intuitive accessible Combination with Backup/Recovery concepts: Memory consumption of the Undo-Information (sometimes) prohibitive expensive E periodic auto save / dump memory image Add backup/recovery points in History Instead of undo restore last backup version and redo until the required state is reached IV-71 Idea for Macro Support Use Composite Pattern to combine multiple low-level commands Use recursive propagation of the Composite pattern with ordered Composite elements to achieve intended composed behaviour composite (Command) composite (Rename) composite (Macro) composite (Command) composite (Save As) composite (Save) IV-72 36

37 Macro Realization Compose multiple commands to a single Macro Command IV-73 Full Command Pattern Structure IV-74 37

38 K M O Q Memento Pattern (Problem) Problem: Commands in the History have to additional store information to recover the old state (undo) Standard: store via cloning a copy of all changed objects, but: J Sometimes to much overhead A reference back can not be used to store referenc back to clone => extra treatment Alternatives: L Create only partial" clone Store only important" attribute and overwrite them for an undo (Problem: encapsulation might restrict attribute access) Idea: N Class itself provides helper object with important data: "Memento" Class can reset its state when some of its Mementos is provided IV-75 Memento Pattern Intent: Capture and externalise an object s state without violating encapsulation Also Known As: Token Related Pattern P Use for Undo with Command Use for Iterator [Gamma+1994] IV-76 38

39 Hooks Pattern Intent: Support several extensions or adaptations to internal operations Example: R Lisp-Systems such as Emacs Related Pattern: S Command Pattern T Interpreter Pattern IV-77 Hooks Pattern Implementation Design aspects: U See Strategy V IMPORTANT: Interface Command / Document W Add dynamically new commands/macros X "Interpreter Commands with script extensions Realize: Y Macros IV-78 39

40 Z [ \ ] III.6 Discussion & Summary Design pattern enable reuse of design experience at the design level! Each design pattern application should be guided by analysing the trade-offs Design pattern are domain independent concepts, but their application in a specific context is guided by the domain specific requirements (time, space) Design patterns generalize concepts that have been successfully employed in real world applications and therefore are bullet proofed! IV-79 III.7 Bibliography (1/1) [Gamma+1994] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns, Elements of Reuseable Object-Oriented Software. Addison-Wesley, IV-80 40