Design Patterns

1. Design Patterns D. Beringer, CS446, 1999

2. What is a Design Pattern? A pattern is a solution to a problem in a context, it documents in an abstract and compact form • the problem • the context in which it occurs • a good solution and it embodies wisdom about how the solution addresses the problem. Pattern “Languages”: set of patterns working together e.g. for real-time telecommunication systems

3. Origins of the Pattern Movement • C. Alexander: patterns in buildings published The Timeless Way of Building and A Pattern Language • GoF patterns: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides published Design Patterns, tried to abstract, name and model the 20 most wide spread design patterns • Conferences on patterns each year new patterns and collection of patterns (pattern languages) are described and presented at PloP (Pattern Languages of Programming)

4. Abstraction Levels Patterns exist on different abstraction levels: • basic building blocks (algorithms and components), provided by language or by libraries • e.g. hash tables, linked lists, sort algorithms, math • e.g. inheritance and polymorphism, encapsulation • design patterns: general design problems in particular context concerning several classes • e.g.GOF-design patterns • architecture patterns: architecture decisions concerning the whole system (or subsystem) • e.g. three-layer architecture, pipe-and-filter architecture ==> differentiation is often fuzzy and language dependent

5. Why Design Patterns? Experience: • good designs require experienced designers/architects • reusing solutions that have worked in the past instead of creating everything new from basic principles • learning from other people’s experience Vocabulary, names for design patterns: • designing and thinking yourself on ahigher abstraction level • communicating about designs and design patterns with other people ==> how would you talk about the architecture of you house if you would not know the words window, door, ...? More than just OO: • finding good classes with right granularity, findingright interaction patterns for a specific task at hand • systems for the future do not represent just current reality: how to find the future-oriented concepts?

6. Essential Elements of a Pattern (1) • Name • Context: situation, domain, problem space in which this pattern is typically used, e.g., designing a GUI, designing a layer that maps objects to a RDBMS, designing a framework, designing a wrapper ... • Problem: the problem the pattern solves, e.g. specific algorithm, adding an undo-redo capabilities, controlling user capabilities based on security level, inflexible object structures, list of specific conditions • same problems appear in different contexts • no pattern solves every problem, sometimes even trade-off necessary • Solution: describes elements that make up the design, their relationships, responsibilities, and collaborations • abstract description of a design problem • general arrangement of elements (classes and objects)

7. Essential Elements of a Pattern (2) • Consequences: results and trade-offs of applying the pattern • constraints due to applying the pattern • constraints solved by the pattern • space and time trade-offs • extensibility and flexibility of resutling system • portability of resulting system • influence on other project specific risks and requirements ==> for evaluating design alternatives ==> for understanding the costs and benefits of applying the pattern

8. Classifying Design Patterns • Granularity, abstraction level • Purpose: • creational • structural: focus is on composition of classes and objects • behavioral: focus is on interaction and responsibility destribution • Scope: • class: focus on class relationships (inheritance) • object: focus is on dynamic run-time relationships (assembly) • Relationships among patterns: • used together • alternatives: same intent, different design with different trade-offs • similarities: similar design, different intent

9. Example: Die 1) Create a die object for a 6-sided die that stores the last 6 values and has the following operations: int prevValue(int) int roll() (d: create this die) 2) Change the die so you can have a loaded die if desired (e.g. with a 30% chance for a 6, or cycling through all numbers, always a constant number, ...). • What is the problem (primary, secondary)? • What are possible solutions (with or without using patterns)?

10. Principles: Composition Inheritance <==> Composition - white-box reuse - black-box reuse - breaks encapsulation, - uses well defined interfaces implementation dependency - larger and fewer object - smaller objects, each object focused on only one task, system’s behavior depends on interrelationships • favor object composition over class inheritance • inherit only from abstract classes with little implementation or from interfaces ==> interface inheritance

11. Patterns with Interface Inheritance • Strategie: strategy object often is abstract class with no implementation or an interface in Java • Chain of Responsibility: objects in chain have common type, but normally do not share any implementation • State: the object state is only an interface with no implementation, the concrete states contain the implementation • context object changes its reference to another state object when state changes • for context objects that have to behave differently at run-time dependant on their state (looks like changing the object class) • for large algorithms with conditional parts dependent on a state • clear separation of state dependent behavior and other behavior Context Request(...) State Handle(...) state method called by clients StateA Handle(...) StateB Handle(...) StateC Handle(...)

12. Small tasks and object • State pattern: different objects for each state and the main object • Command pattern: • participants: Command, ConcreteCommand, Client, Invoker, Receiver • abstract pattern see GoF-book • extendable to handle also macro-commands • undo-command: add UnExecute to the command interface, store executed commands in a list Application add(Document) Menu …. MenuItem clicked(..): calls execute Command execute(..) 1 * * Document open(..) close(..) copy(..) paste(..) PasteCommand execute(...): calls paste of Document OpenCommand execute(...): gets document name from user, creates document objects and calls add of Application creates

13. Command pattern Client Invoker Command execute() 1 creates and sets up everything, makes sure each invoker has its command object ConcreteCommand execute (): calls receiver.action() and maybe state Receiver action() receiver

14. Principles: Delegation Inheritance <==> Delegation with Composition - subclass defers request - delegate defers request to receiver to superclass and gets result to be returned from r. - implicit delegation - explicitdelegation - reference to superclass - receiver gives its reference to delegate by inheritance prior to any requests ==> composition - avoids multiple inheritance Rectangle width height Area() ? Window other operations

15. Examples for Delegation • State pattern • Strategy pattern • Visitor pattern: Situation: you have some object structure consisting of different object types (e.g. a tree with different kind of nodes), and you have (new additional) operations that have to be implemented differently for each node type. Instead of adding these operations to the nodes, you define for each operation type a class that contains a visitNodeX method for each node type. :Client a:NodeTypeA b:NodeTypeB m1:VisitorMethod1 accept(m1:Visitor) visitNoteTypeA(a) accessing state needed for operation accept(m2:Visitor) visitNoteTypeA(a) accept(m1:Visitor) visitNoteTypeB(b) call various methods

16. Principle: Subsystems Why subsystems? • too many objects, complexity (OO-spaghetti-code) • parallel/incremental development by independent developers • reuse White-box <==> black-box subsystems • knowledge of and dependency on structure • direct requests or message dispatching • references from users How do you make a black-box subsystem, and how do you call the mechanism you are using?

17. Subsystems: Façade Pattern Façade: defines a clean, high-level interface to a subsystem, hiding its structure Context: building easy-to-use and maintain subsystems Problem: Each class in the subsystem provides part of the subsystem’s functionality ==> client of subsystem has to know structure of it, changes to the subsystem may require changes to the clients (high coupling and dependency!) Solution: Add an interface class (the façade class) that knows the structure of the subsystem and forwards requests… Consequences: no or less (if still direct references are allowed) dependency of client from structure of subsystem, ideal for layered subsystems Facade

18. Using Design Patterns (1) Solution has to be principle oriented (encapsulation, inerfaces, delegation, loose coupling, high cohesion), patterns can fulfill principles and can help when principles are conflicting! Do patterns replace thinking? • Patterns represent knowledge, yet this knowledge still has to be acquired, even if the acquisition is made easy • Patterns have to be tailored to a concrete problem, and implemented • Choosing among patterns, and combining them, is no automatic process!

19. Using Design Patterns (2) 1) Understand problem and context • What is the problem? What is the context? • What is the abstraction of the problem? • Deals it with the creation, structure or behavior of objects? 2) Find a pattern • If no pattern: find a non-pattern solution 3) Map structure 4) Evaluate fit • benefits outweigh consequences • check principles • If bad fit: go back and try alternative pattern 5) Implement and evaluate result • If result does not satisfy: go back and try alternative pattern, or implement non-pattern solution

20. Redesign Software As an application grows it often becomes too complex, too hacked together, necessitating a redesign. Some causes for redesigns: 1) Objects are created by specifying their class name, inhibiting flexibility of which subclass is created ==> create object indirectly (patterns: abstract factory, factory method, prototype) 2) Adapting legacy codeand interfaces when legacy source is either not available or too many classes need to be changed with unknown side-effects ==> use adapter classes (patterns: adapter, decorator, visitor) 3) Algorithmic dependencies when algorithms are likely to be changed, extended, replaced during development and reuse ==> isolate algorithm (patterns: builder, iterator, strategy, template method, visitor) 4) Dependence on specific operations, hard-coded how requests are satisfied (patterns: command, chain of responsibility) 5) Tight coupling (patterns: façade, bridge, command, observer, …) etc...

21. Architecture Patterns • concern architecture of whole system or subsystem • also called architecture styles • often heterogeneous systems • often loosely described or modeled by UML subsystem diagrams • or formally specified (and simulated) by architecture description languages • implementation can differ depending on available languages and OS • see also “Software Architecture” by M.Shaw and D. Garlan

22. Examples for Architecture Patterns (1) Pipes and Filters: • Filters are independent entities for processing: • no shared state • no knowledge about other filters • Pipes connect entities and provide dataflow • Special cases: • Pipelines: linear sequence of filters • Bounded pipes: amount of data on each pipe is restricted • Typed pipes: pipes only allow data of specified type • Batch sequential system: a filter processes all of its input data as a single entity • Examples: • Unix shell programs • signal processing systems • parallel programming, functional programming

23. Examples for Architecture Patterns (2) • Client-Server architectures • Layered architecture • Repository architecture (e.g. batch-sequential systems with global database, tool integration), blackboard modelfor problem solving • Event based systems (event broadcasting, subscribing for events, CORBA event services, ... ) • announcers of events do not know which components will be affected by those events • State transition system (system defined in terms of states and a set of transition that move the system from state to state)

24. References • http://st-www.cs.uiuc.edu/users/patterns/patterns.html the pattern home page • http://c2.com Portland Pattern Repository and WikiWikiWeb • http://www.enteract.com/~bradapp/ links to pattern pages • for subscribing to mailing lists about patterns send an email with subscribe in the subject to patterns-request@cs.uiuc.edu orpatterns-discussion-request@cs.uiuc.edu • Larman, C: Applying UML and Patterns, Prentice-Hall, 1997 • Fowler, M: Analysis Patterns: Reusable Object Models, 1997 • Pattern Languages of Program Design 1, 2, and 3, all published by Addison-Wesley, patterns for a wide variety of problem domains • Buschman, F. et al: Pattern-Oriented Software Architecture - A System of Patterns, 1996

25. Frameworks - Design Patterns Frameworks <==> Design patterns - to be reused directly, - only examples are in code, embodied in code need be implemented each time - more specialized - more abstract, can be used in many different kind of systems - large, system-level solution, - small can contain several design pattern - off-the-shelf solution - explain intent, trade-offs, consequences