Classifying Relationships Between Object-Oriented Design Patterns

Total Page:16

File Type:pdf, Size:1020Kb

Classifying Relationships Between Object-Oriented Design Patterns Classifying Relationships Between Object-Oriented Design Patterns James Noble Microsoft Research Institute Macquarie University Sydney, Australia [email protected] Abstract ing its own idiomatic classification of these relation- ships. This inconsistency can make patterns difficult Since the publication of the Design Patterns book, to use, because a pattern’s relationships to other pat- a large number of object-oriented design patterns terns is an important part of a pattern’s definition, and have been identified and codified. As part of the pat- inconsistent definitions make it difficult for readers to tern form, object-oriented design patterns must indi- understand the relationships intended by any particu- cate their relationships with other patterns, but these lar description. relationships are typically described very briefly, and In this paper, we present a classification scheme different collections of patterns describe different re- for the relationships between design patterns. This lationships in different ways. In this paper we de- scheme is based on three primary relationships be- scribe and classify the common relationships between tween patterns — a pattern uses another pattern, a pat- object oriented design patterns. Practitioners can use tern refines another pattern, or a pattern conflicts with these relationships to help them identity those pat- another pattern. The paper also describes a number of terns which may be applicable to a particular prob- secondary relationships between patterns, such as a lem, and pattern writers can use these relationships pattern being similar to another pattern, or one pattern to help them integrate new patterns into the body of combining with another pattern, and shows how these the patterns literature. secondary relationships can be expressed in terms of the primary relationships. This paper is organised as follows. Section 2 1. Introduction briefly reviews object-oriented design patterns and the major constituents of the pattern form. Section 3 de- scribes the structure of our classification scheme, and A design pattern is a “description of communicat- enumerates the relationships we describe. Section 4 ing objects and classes that are customised to solve a then presents the primary relationships in our classifi- general design problem in a particular context” [12, cation scheme in detail, and Section 5 describes how p.3]. Designers can incorporate patterns into their the secondary relationships between patterns can be program to address general problems in the structure expressed in terms of the primary relationships. Sec- of their programs’ designs, in a similar way that al- tion 6 concludes the paper. gorithms or data structures are incorporated into pro- grams to solve particular computational or storage problems. A growing body of literature catalogues 2. Object-Oriented Design Patterns patterns for object-oriented design, including refer- ence texts such as Design Patterns [12] or Patterns A design pattern is an abstraction from a con- of Software Architecture [5], and patterns compendia crete recurring solution that solves a problem in a such as the Pattern Languages of Program Design se- certain context [12, 5]. Design patterns were devel- ries [6, 28, 17]. oped by an architect, Christopher Alexander, to de- Design patterns do not stand alone — rather each scribe techniques for town planning, architectural de- pattern is related other patterns in a variety of ways, signs, and building construction techniques and de- and the text of each pattern should describe these re- scribed in Alexander’s A Pattern Language Towns, lationships. Unfortunately, each pattern text book or Building Construction [1]. Design patterns were first catalogue describes relationships between patterns us- applied to software by Kent Beck and Ward Cunning- 1 ham to describe user interface design techniques [4], sification scheme for relationships between patterns and were then popularised by the Design Patterns cat- presented in this paper was developed to support the alogue, which described twenty-three general purpose wider goal of organising patterns in the Found Ob- patterns for object oriented design. Since Design Pat- jects project, by identifying the most important rela- tern’s publication, a large number of other patterns tionships between patterns. have been identified and published [5, 3, 2, 6, 28, 17]. More recently, different types of patterns have been 3. Classifying Relationships between identified, including Composite Patterns [25] and Pat- tern Tilings [14]. Patterns A design pattern is written in pattern form, that is Figure 1 illustrates the structure of our classifica- in one of a family of literary styles designed to make tion scheme for relationships between patterns. The patterns easy to apply. A design pattern has a name classification scheme is based on three primary re- to facilitate communication about programs in terms lationships between patterns — one pattern uses an- of patterns, a description of the problems for which other pattern; a more specific pattern refines a more the pattern is applicable, an analysis of the forces ad- general pattern, and one pattern conflicts with another dressed by the pattern and the important considera- pattern when they both propose solutions to a similar tions and consequences of using the pattern, a sam- problem. These three relationships are described in ple implementation of the pattern’s solution, and ref- Section 4. erences to known uses of the pattern. The scheme also describes a number of secondary Most importantly from the perspective of this pa- relationships between patterns, such as a pattern be- per, a pattern lists other patterns which are in some ing a variant of another pattern, two patterns being way related. The problem addressed by this paper is similar, or two patterns combining to solve a prob- that different collections of patterns describe different lem. Section 5 presents the secondary relationships, relationships between patterns in different ways. For and describes how they can be expressed in terms of example, the relationships between object-oriented the primary relationships. design patterns were first analysed by Walter Zimmer, who studied the relationships between patterns in De- sign Patterns[12]. According to Zimmer [31], there 4. Primary Relationships are three relationships — one pattern can use another pattern; a variant of one pattern can use another pat- Our classification scheme is based on three pri- tern; and one pattern can be similar to another pattern. mary relationships between patterns — uses, refines, The Design Patterns Smalltalk Companion includes and conflicts. In this section we outline these three re- these three relationships, but introduces a fourth re- lationships, present examples of well-known patterns lationship — one pattern can be a specialisation of which exhibit these relationships, and provide a sim- another pattern [2]. Patterns of Software Architec- ple graphical notation which can illustrate these rela- ture describes three kinds of relationships between tionships between groups of patterns. patterns, including Zimmer’s first relationship and in- troducing two more — one pattern can be a variant 4.1. Uses of another pattern; and two patterns can be used in combination to solve a problem [5]. Meszaros and Almost every pattern form records the patterns Doble’s Patterns for Pattern Writing [18] identify five which each pattern uses — that is, patterns which relationships between patterns — a pattern can use, be help another pattern. Typically, a pattern which has used by, generalise, specialise, or provide an alterna- a larger or more global impact on a design will use tive to another pattern. Other patterns or collections of patterns which have smaller or more local impacts. patterns describe other relationships between patterns The uses relationship is the only explicit relation- and recent work has discussed compositional and re- ship between patterns in Alexander’s original archi- flexive relationships between patterns [27, 25, 14]. tectural patterns [1]. Alexander’s patterns are organ- We are engaged in a long-term project called ised into a pattern language based on this relation- “Found Objects” that aims to organise patterns for ship — that is, the patterns are organised so that each object-oriented design [19, 20, 21, 23]. As part of pattern is followed by the other smaller-scale patterns this project, we have analysed existing patterns to de- which it uses, and which should be considered once termine their relationships to other patterns. We have the large-scale pattern has been chosen. For example, identified new patterns, and then related these patterns the Small Public Squares pattern uses the Pedestrian to the existing patterns in the literature. The clas- Density, Activity Pockets, and Something Roughly in 2 Primary Relationships Uses One pattern uses another pattern [1, 12, 31] Refines A specific pattern refines a general pattern [2, 18] Conflicts A pattern addresses the same problem as another pattern [8, 3] Secondary Relationships Used by A smaller pattern is used by a larger pattern [1] Refined by A general pattern is refined by a specific pattern [18] Variant A variant pattern refines a more well-known pattern [5] Variant Uses A variant of one pattern uses another pattern [31] Similar A pattern is similar to another pattern [31] Combines Two patterns combine to solve a single problem [5, 8] Requires A pattern requires the solution of another pattern [7] Tiling A pattern uses itself [14] Sequence of A sequence of patterns from the simple to the complex [26, 11] Elaboration Figure 1. The Structure of the Classification Scheme the Middle patterns. The Small Public Squares pattern describe how these patterns are combined into the is a larger scale pattern because it describes the design composite pattern, for example, by using role dia- of the entire square; the other patterns are smaller be- grams [25]. Following Zimmer [31], Figure 2 shows cause they describe the pedestrian traffic in the square, how the structure of uses relationships can be illus- the edges of the square, and the centre of the square trated graphically. respectively.
Recommended publications
  • (GOF) Java Design Patterns Mock Exams
    Gang of Four (GOF) Java Design Patterns Mock Exams http://www.JavaChamp.com Open Certification Plattform Authors: N. Ibrahim, Y. Ibrahim Copyright (c) 2009-2010 Introducing JavaChamp.com Website JavaChamp.com is an Open Certification Platform. What does this mean? JavaChamp is the best place to learn, share, and certify your professional skills. We help you develop yourself in the field of computer science and programming Here are the most significant features offered by JavaChamp: Online Exams Start Online Certification Exams in SCJP, SCEA, EJB, JMS, JPA and more... Top quality mock exams for SCJP, SCEA, EJB, JMS, JPA. Start Express or topic-wise customized exam. * We offer you unlimited free mock exams * Exams cover subjects like SCJP, SCEA, EJB, JMS, JPA,.. * You can take as many exams as you want and at any time and for no charges * Each exam contains 20 multiple choice questions * You can save the exams taken in your exams history * Your exams history saves the exams you took, the scores you got, time took you to finish the exam, date of examination and also saves your answers to the questions for later revision * You can re-take the same exam to monitor your progress * Your exams history helps the system to offer you variant new questions every time you take a new exam, therefore we encourage you to register and maintain an exams history Network Find guidance through the maze, meet Study-Mates, Coaches or Trainees... Studying together is fun, productive and helps you in building your professional network and collecting leads Bookshelf JavaChamp Bookshelf full of PDF eBooks..
    [Show full text]
  • Usage of Factory Design Pattern
    What is a Creational Pattern? Creational Patterns are concerned with object creation problems faced during software design. Object creation often results in design problems, creational patterns solve this problem by controlling the object creation. Factory pattern A Factory Pattern or Factory Method Pattern says that just define an interface or abstract class for creating an object but let the subclasses decide which class to instantiate. In other words, subclasses are responsible to create the instance of the class. The Factory Method Pattern is also known as Virtual Constructor. A Factory returns an instance of an object based on the data supplied to it. The instance returned can be one of many classes that extend a common parent class or interface. ("Animal" as a parent class, then "Dog", "Cat", "Zebra" as child classes.) Create objects without exposing their instantiation logic. Consequences: The requestor is independent of the concrete object that is created (how that object is created, and which class is actually created). Advantage of Factory Design Pattern Factory Method Pattern allows the sub-classes to choose the type of objects to create. It promotes the loose-coupling by eliminating the need to bind application-specific classes into the code. That means the code interacts solely with the resultant interface or abstract class, so that it will work with any classes that implement that interface or that extends that abstract class. Usage of Factory Design Pattern When a class doesn't know what sub-classes will be required to create When a class wants that its sub-classes specify the objects to be created.
    [Show full text]
  • One-Slide Summary Lecture Outline
    Using Design Patterns #1 One-Slide Summary • Design patterns are solutions to recurring OOP design problems. There are patterns for constructing objects, structuring data, and object behavior . • Since this is PL, we’ll examine how language features like (multiple) inheritance and dynamic dispatch relate to design patterns. #2 Lecture Outline • Design Patterns • Iterator • Observer • Singleton • Mediator #3 1 What is a design pattern? • A solution for a recurring problem in a large object-oriented programming system – Based on Erich Gamma’s Ph.D. thesis, as presented in the “gang of four” book • “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” – Charles Alexander #4 Types of design patterns • Design patterns can be (roughly) grouped into three categories: • Creational patterns – Constructing objects • Structural patterns – Controlling the structure of a class, e.g. affecting the API or the data structure layout • Behavioral patterns – Deal with how the object behaves #5 Iterator design pattern • Often you may have to move through a collection – Tree (splay, AVL, binary, red-black, etc.), linked list, array, hash table, dictionary, etc. • Easy for arrays and vectors • But hard for more complicated data structures – Hash table, dictionary, etc. • The code doing the iteration should not have to know the details of the data structure
    [Show full text]
  • Design Case Study: Java Swing
    Principles of Software Construction: Objects, Design, and Concurrency Part 2: Design case studies Design case study: Java Swing Charlie Garrod Chris Timperley 17-214 1 Administrivia • Reading due today: UML and Patterns 26.1 and 26.4 • Homework 4b due Thursday, October 17th https://commons.wikimedia.org/wiki/File:1_carcassonne_aerial_2016.jpg 17-214 2 Key concepts from Thursday • Observer design pattern • Introduction to concurrency – Not enough synchronization: safety failure – Too much synchronization: liveness failure • Event-based programming • Introduction to GUIs 17-214 3 GUI programming is inherently multi-threaded • Swing event dispatch thread (EDT) handles all GUI events – Mouse events, keyboard events, timer events, etc. • No other time-consuming activity allowed on the EDT – Violating this rule can cause liveness failures 17-214 4 Swing has many event listener interfaces • ActionListener • MouseListener • AdjustmentListener • TreeExpansionListener • FocusListener • TextListener • ItemListener • WindowListener • KeyListener • … class ActionEvent { int when; String actionCommand; int modifiers; Object source(); int id; … interface ActionListener { } void actionPerformed(ActionEvent e); } 17-214 5 Aside: lambdas vs. explicit class declarations? //static public void main… JFrame window = … JPanel panel = new JPanel(); window.setContentPane(panel); panel to hold the button JButton button = new JButton(“Click me”); button.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { System.out.println(“Button
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Object-Oriented Analysis, Design and Implementation
    Undergraduate Topics in Computer Science Brahma Dathan Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition Undergraduate Topics in Computer Science Undergraduate Topics in Computer Science (UTiCS) delivers high-quality instruc- tional content for undergraduates studying in all areas of computing and information science. From core foundational and theoretical material to final-year topics and applications, UTiCS books take a fresh, concise, and modern approach and are ideal for self-study or for a one- or two-semester course. The texts are all authored by established experts in their fields, reviewed by an international advisory board, and contain numerous examples and problems. Many include fully worked solutions. More information about this series at http://www.springer.com/series/7592 Brahma Dathan • Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition 123 Brahma Dathan Sarnath Ramnath Department of Information and Computer Department of Computer Science Science and Information Technology Metropolitan State University St. Cloud State University St. Paul, MN St. Cloud, MN USA USA Series editor Ian Mackie Advisory Board Samson Abramsky, University of Oxford, Oxford, UK Karin Breitman, Pontifical Catholic University of Rio de Janeiro, Rio de Janeiro, Brazil Chris Hankin, Imperial College London, London, UK Dexter Kozen, Cornell University, Ithaca, USA Andrew Pitts, University of Cambridge, Cambridge, UK Hanne Riis Nielson, Technical University of Denmark, Kongens Lyngby, Denmark Steven Skiena, Stony Brook University, Stony Brook, USA Iain Stewart, University of Durham, Durham, UK A co-publication with the Universities Press (India) Private Ltd., licensed for sale in all countries outside of India, Pakistan, Bhutan, Bangladesh, Sri Lanka, Nepal, The Maldives, Middle East, Malaysia, Indonesia and Singapore.
    [Show full text]
  • Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel
    Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel Kelt Dockins [email protected] Design Patterns in PHP and Laravel Kelt Dockins Dolph, Arkansas USA ISBN-13 (pbk): 978-1-4842-2450-2 ISBN-13 (electronic): 978-1-4842-2451-9 DOI 10.1007/978-1-4842-2451-9 Library of Congress Control Number: 2016961807 Copyright © 2017 by Kelt Dockins This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made.
    [Show full text]
  • Design Patterns Design Patterns
    Design Patterns CSC207 – Software Design Design Patterns • Design pattern: – A general description of the solution to a well- established problem using an arrangement of classes and objects. • Patterns describe the shape of code rather than the details. – There are lots of them in CSC 301 and 302. Loop patterns from first year • Loop pattern: – A general description of an algorithm for processing items in a collection. • All of you (hopefully) have some loop patterns in your heads. • You don’t really need to think about these any more; you just use them, and you should be able to discuss them with your fellow students. • Some first-year patterns: – Process List – Counted Loop – Accumulator – Sentinel Process list pattern • Purpose: to process every item in a collection where you don’t care about order or context; you don’t need to remember previous items. • Outline: • Example: • Other example: darken every pixel in a picture Counted loop pattern • Purpose: to process a range of indices in a collection. • Outline: • Example: • Other example: print indices of even-length string Accumulator pattern • Purpose: to accumulate information about items in a collection. • Outline: • Example: • Other examples: sum, min, accumulate a list of items meeting a particular criterion. Sentinel pattern • Purpose: to remove a condition in a loop guard. • Outline: • Example: Sentinel pattern, continued • Here is the code that Sentinal replaces; note that i != list.size() is evaluated every time through the loop, even though it is false only once. Design Pattern
    [Show full text]
  • Facet: a Pattern for Dynamic Interfaces
    Facet: A pattern for dynamic interfaces Author: Eric Crahen SUNY at Buffalo CSE Department Amherst, NY 14260 201 Bell Hall 716-645-3180 <[email protected]> Context: Wherever it is desirable to create a context sensitive interface in order to modify or control the apparent behavior if an object. Problem: How can I modify the behavior of an existing object so that different behaviors are shown under different circumstances; and yet still maintain a clean separation between the policy (when each behavior is available) and implementation of each behavior allowing them to be developed independently of one another? Forces: Interfaces provide an essential level of abstraction to object oriented programming. Generally, objects are able define aspects of their function very well using interfaces. At times, this may not be enough. When dealing with two or more classes whose responsibilities are distinctly separate, but whose behavior is closely related, classes can begin to resist modularization. For example, adding security to an application means inserting code that performs security checks into numerous locations in existing classes. Clearly, these responsibilities are distinct; the original classes being responsible for the tasks they were designed to perform, and the security classes being responsible for providing access control. However, making those original classes secure means intermingling code that deals with security. When the classes dealing with security are changed many classes are going to be impacted. One method of adding new behavior to an existing class might be to simply create a subclass and embed that new behavior. In the security example, this would mean creating a subclass for each class that needs to be secure and adding calls to the security code.
    [Show full text]
  • Lecture 1 for Chapter 8, Object Design: Reusing Pattern Solutions
    Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 8, Object Design: 8, Object Chapter Reuse and Patterns I and Patterns Reuse Object Design Object design is the process of adding details to the requirements analysis and making implementation decisions The object designer must choose among different ways to implement the analysis model with the goal to minimize execution time, memory and other measures of cost Requirements Analysis: Use cases, functional and dynamic model deliver operations for object model Object Design: Iterates on the models, in particular the object model and refine the models Object Design serves as the basis of implementation System Development as a Set of Activities System Problem Application objects Analysis Solution objects Design Custom objects - Object Design Off-the-Shelf Components - System Design Existing Machine Examples of Object Design Activities Identification of existing components Full definition of associations Full definition of classes (System Design => Service, Object Design => Subsystem interfaces/API) Choosing algorithms and data structures Identifying possibilities of reuse Detection of solution-domain classes Optimization Increase of inheritance Decision on control …… A More Detailed View of Object Design Activities Select Subsystem Specification Reuse Identifying missing Identifying components attributes & operations Specifying visibility Adjusting components Specifying types & signatures Identifying patterns Specifying constraints Specifying exceptions
    [Show full text]
  • Behavioral Patterns
    Behavioral Patterns 101 What are Behavioral Patterns ! " Describe algorithms, assignment of responsibility, and interactions between objects (behavioral relationships) ! " Behavioral class patterns use inheritence to distribute behavior ! " Behavioral object patterns use composition ! " General example: ! " Model-view-controller in UI application ! " Iterating over a collection of objects ! " Comparable interface in Java !" 2003 - 2007 DevelopIntelligence List of Structural Patterns ! " Class scope pattern: ! " Interpreter ! " Template Method ! " Object scope patterns: ! " Chain of Responsibility ! " Command ! " Iterator ! " Mediator ! " Memento ! " Observer ! " State ! " Strategy ! " Visitor !" 2003 - 2007 DevelopIntelligence CoR Pattern Description ! " Intent: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. ! " AKA: Handle/Body ! " Motivation: User Interfaces function as a result of user interactions, known as events. Events can be handled by a component, a container, or the operating system. In the end, the event handling should be decoupled from the component. ! " Applicability: ! " more than one object may handle a request, and the handler isn't known a priori. ! " Want to issue a request to one of several objects without specifying the receiver !" 2003 - 2007 DevelopIntelligence CoR Real World Example ! " The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver, by giving more than one object a chance to handle the request. ! " Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank.
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]