Design Pattern and Software Architecture: IV. Design Pattern AG Softwaretechnik Raum E 3.165 Tele.. 60-3321 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.5 Structural Pattern Composite, Decorator, Bridge, Adapter IV.4 Behavioural Pattern Observer, Iterator, Strategy, Hook, Template Method, Visitor, Command, Memento IV.6 Discussion & Summary IV.7 Bibliography IV-2 1
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,... 4. User Interface 5. Different Look-And-Feels 6. Different Window systems 7. Undo/Redo, Macros,... IV-4 2
Coarse Grain Design Software Architecture IV-5 Internal Representation? IV-6 3
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
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
Manage GUI Elements? IV-11 Support Multiple Window Systems IV-12 6
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
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
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
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
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
" 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