Elements of Reusable
`Object-Oriented Software
`Erich Gamma
`Richard Helm
`Ralph Johnson
`John Vlissides
`
`Cover art© 1994 M .C. Escher I Cordon Art - Baarn - Holland. All rights reserved.
`
`Foreword by Grady Booch
`
`w ~4 •
`
`:....t
`
`-
`
`Lindsay Corporation
`IPR2015-01039
`
`Exhibit 1019 - 1
`
`

`
`Material from A Pattern Language: Towns/Buildings/Construction by Christopher Alexander,
`copyright © 1977 by Christopher Alexander is reprinted by permission of Oxford University
`Press, Inc.
`
`Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
`trademarks. Where those designations appear in this book, and we were aware of a trademark claim, the
`designations have been printed in initial capital letters or in all capitals.
`
`The author and publisher have taken care in the preparation of this book, but make no expressed or
`implied warranty of any kind and assume no responsibility for errors or !omissions. No liability is
`assumed for incidental or consequential damages in connection with or arising out of the use of the
`information or programs contained herein.
`
`The publisher offers discounts on this book when ordered in quantity for special sales. For more informa(cid:173)
`tion, please contact:
`
`Pearson Education Corporate Sales Division
`201 W. 103rd Street
`Indianapolis, IN 46290
`(800) 428-5331
`corpsales@pearsoned.com
`
`Visit AW on the Web: www.awl.com/cseng/
`
`Library of Congress Cataloging-in-Publication Data
`Design Patterns : elements of reusable object-oriented software I Erich Gamma ... [et al.].
`p. cm.-(Addison-Wesley professional computing series)
`Includes bibliographical references and index.
`ISBN 0-201-63361-2
`1. Object-oriented programming (Computer science) 2. Computer software-Reusability.
`I. Gamma, Erich. II. Series.
`QA 76.64.D47 1994
`005.1'2-dc20
`
`94-34264
`CIP
`
`Copyright © 1995 by Addison-Wesley
`
`All rights reserved. No part of this publication may be reproduced , stored in a retrieval system, or
`transmitted, in any form , or by any means, electronic, mechanical, photocopying, recording , or other(cid:173)
`wise, without the prior consent of the publisher. Printed in the United States of America. Published
`simultaneously in Canada.
`
`Cover art© M.C. Escher/Cordon Art - Baam - Holland. All rights reserved .
`
`Text printed on recycled and acid-free paper.
`
`ISBN 0201633612
`23 2425262728 CR W 05 04 03 02
`
`23rd Printing March 2002
`
`Lindsay Corporation
`IPR2015-01039
`
`Exhibit 1019 - 2
`
`

`
`4
`
`INTRODUCTION
`
`CHAPTER 1
`
`and the distribution of responsibilities. Each design pattern focuses on a particular
`object-oriented design problem or issue. It describes when it applies, whether it can be
`applied in view of other design constraints, and the consequences and trade-offs of its
`use. Since we must eventually implement our designs, a design pattern also provides
`sample C++ and (sometimes) Smalltalk code to illustrate an implementation.
`
`Although design patterns describe object-oriented designs, they are based on practical
`solutions that have been implemented in mainstream object-oriented programming
`languages like Smalltalk and C++ rather than procedural languages (Pascal, C, Ada) or
`more dynamic object-oriented languages (CLOS, Dylan, Self). We chose Smalltalk and
`C++ for pragmatic reasons: Our day-to-day experience has been in these languages,
`and they are increasingly popular.
`
`The choice of programming language is important because it influences one's point
`of view. Our patterns assume Smalltalk/C++-level language features, and that choice
`determines what can and cannot be implemented easily. If we assumed procedural
`languages, we might have included design patterns called "Inheritance," "Encapsu(cid:173)
`lation," and "Polymorphism." Similarly, some of our patterns are supported directly
`by the less common object-oriented languages. CLOS has multi-methods, for example,
`which lessen the need for a pattern such as Visitor (page 331). In fact, there are enough
`differences between Smalltalk and C++ to mean that some patterns can be expressed
`more easily in one language than the other. (See Iterator (257) for an example.)
`
`1.2 Design Patterns in Smalltalk MVC
`
`The Model/View /Controller (MVC) triad of cla·sses [KP88] is used to build user inter(cid:173)
`faces in Smalltalk-SO. Looking at the design patterns inside MVC should help you see
`what we mean by the term "pattern."
`
`MVC consists of three kinds of objects. The Model is the application object, the View is
`its screen presentation, and the Controller defines the way the user interface reacts to
`user input. Before MVC, user interface designs tended to lump these objects together.
`MVC decouples them to increase flexibility and reuse.
`
`MVC decouples views and models by establishing a subscribe/ notify protocol between
`them. A view must ensure that its appearance reflects the state of the model. Whenever
`the model's data changes, the model notifies views that depend on it. In response, each
`view gets an opportunity to update itself. This approach lets you attach multiple views
`to a model to provide different presentations. You can also create new views for a model
`without rewriting it.
`
`The following diagram shows a model and three views. (We've left out the controllers
`for simplicity.) The model contains some data values, and the views defining a spread(cid:173)
`sheet, histogram, and pie chart display these data in various ways. The model commu(cid:173)
`nicates with its views when its values change, and the views communicate with the
`model to access these values.
`
`Lindsay Corporation
`IPR2015-01039
`
`Exhibit 1019 - 3
`
`

`
`-ECTION 1.2
`
`DESIGN PATTERNS IN SMALLTALK MVC
`
`5
`
`views
`
`w
`
`c
`a
`b
`x 60 30 10
`v 50 30 20
`z 80 10 10
`
`model
`
`en at face value, this example reflects a design that decouples views from models. But
`--e design is applicable to a more general problem: decoupling objects so that changes
`- one can affect any number of others without requiring the changed object to know
`-
`ails of the others. This more general design is described by the Observer (page 293)
`ign pattern.
`__ other feature of MVC is that views can be nested. For example, a control panel of
`ons might be implemented as a complex view containing nested button views. The
`~~r interface for an object inspector can consist of nested views that may be reused in
`" ebugger. MVC supports nested views with the Composite View class, a subclass of
`- ew. Composite View objects act just like View objects; a composite view can be used
`•. erever a view can be used, but it also contains and manages nested views.
`- gain, we could think of this as a design that lets us treat a composite view just like
`·e treat one of its components. But the design is applicable to a more general problem,
`-. ·ch occurs whenever we want to group objects and treat the group like an individual
`. This more general design is described by the Composite (163) design pattern. It
`you create a class hierarchy in which some subclasses define primitive objects (e.g.,
`-= i on) and other classes define composite objects (Composite View) that assemble the
`--'.mitives into more complex objec~~-
`- :c also lets you change the way a view responds to user input without changing its
`...:ual presentation. You might want to change the way it responds to the keyboard, for
`ple, or have it use a pop-up menu instead of command keys. MVC encapsulates
`response mechanism in a Controller object. There is a class hierarchy of controllers,
`· git easy to create a new controller as a variation on an existing one.
`
`Lindsay Corporation
`IPR2015-01039
`
`Exhibit 1019 - 4
`
`

`
`6
`
`INTRODUCTION
`
`CHAPTER 1
`
`A view uses an instance of a Controller subclass to implement a particular response
`strategy; to implement a different strategy, simply replace the instance with a different
`kind of controller. It's even possible to change a view's controller at run-time to let the
`view change the way it responds to user input. For example, a view can be disabled so
`that it doesn't accept input simply by giving it a controller that ignores input events.
`The View-Controller relationship is an example of the Strategy (315) design pattern.
`A Strategy is an object that represents an algorithm. It's useful when you want to
`replace the algorithm either statically or dynamically, when you have a lot of variants
`of the algorithm, or when the algorithm has complex data structures that you want to
`encapsulate.
`MVC uses other design patterns, such as Factory Method (107) to specify the default
`controller class for a view and Decorator (175) to add scrolling to a view. But the
`main relationships in MVC are given by the Observer, Composite, and Strategy design
`patterns.
`
`1.3 Describing Design Patterns
`
`How do we describe design patterns? Graphical notations, while important and useful,
`aren't sufficient. They simply capture the end product of the design process as rela(cid:173)
`tionships between classes and objects. To reuse the design, we must also record the
`decisions, alternatives, and trade-offs that led to it. Concrete examples are important
`too, because they help you see the design in action.
`We describe design patterns using a cons~~tent format. Each pattern is divided into
`sections according to the following template. The template lends a uniform structure
`to the information, making design patterns easier to learn, compare, and use.
`
`Pattern Name and Classification
`The pattern's name conveys the essence of the pattern succinctly. A good name
`is vital, because it will become part of your design vocabulary. The pattern's
`classification reflects the scheme we introduce in Section 1.5.
`
`Intent
`A short statement that answers the following questions: What does the design
`pattern do? What is its rationale and intent? What particular design issue or
`problem does it address?
`
`Also Known As
`Other well-known names for the pattern, if any.
`
`Motivation
`A scenario that illustrates a design problem and how the class and object structures
`
`Lindsay Corporation
`IPR2015-01039
`
`Exhibit 1019 - 5