Design Patterns:Elements of Reusable object-Oriented Software The purpose of this book is to record experience in designing object-oriented are as desion patterns.Each design pattern systematically names,expa ortant and recurring sys goal is to capture design experience in a form that people can use effectively. To this end we have documented some of the most important design patterns and present them as a catalog. Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers o that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent.Put simply,design patterns help a designer get a design "right"fas None of the design patterns in this book describes new or unproven designs.We have included only designs that have been applied more than once in different systems.Most of these designs have never been documented before.They are either part of the folklore of the object-oriented community or are elements of some auccesstul object-oriented systems-neither ot which is easy for novice designers to ugh t designs aren't capture them and accessible way:as a catalog of design patterns having a consistent format Despite the book's size,the design patterns in it capture only a fraction of what an expert might know.It doesn't have any patterns dealing with concurrency or distributed programming or real-time programming.It doesn't have any application domain -specific patterns.It doesn't tell you how to build how tow ice drive o u: d database Each of these areas has its own patterns,and it would be worthwhile for someone to catalog those too. What is a Design Pattern? Christopher Alexander says,"Each pattern describes a problem which occurs over and over aga in our enviror ment then describe es the core of th 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"[AIS+771.Even though Alexander was talking about patterns in buildings and towns,what he says is true about obiect-oriented design patterns.our solutions are expressed in terms of obiects and interfaces instead of walls and doors,but at the core of both kinds of patterna is a solution to a problem in a context In general,a pattern has four essential elements: 12
Design Patterns: Elements of Reusable Object-Oriented Software 12 The purpose of this book is to record experience in designing object-oriented software as design patterns. Each design pattern systematically names, explains, and evaluates an important and recurring design in object-oriented systems. Our goal is to capture design experience in a form that people can use effectively. To this end we have documented some of the most important design patterns and present them as a catalog. Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent. Put simply, design patterns help a designer get a design "right" faster. None of the design patterns in this book describes new or unproven designs. We have included only designs that have been applied more than once in different systems. Most of these designs have never been documented before. They are either part of the folklore of the object-oriented community or are elements of some successful object-oriented systems—neither of which is easy for novice designers to learn from. So although these designs aren't new, we capture them in a new and accessible way: as a catalog of design patterns having a consistent format. Despite the book's size, the design patterns in it capture only a fraction of what an expert might know. It doesn't have any patterns dealing with concurrency or distributed programming or real-time programming. It doesn't have any application domain-specific patterns. It doesn't tell you how to build user interfaces, how to write device drivers, or how to use an object-oriented database. Each of these areas has its own patterns, and it would be worthwhile for someone to catalog those too. What is a Design Pattern? Christopher Alexander says, "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" [AIS+77]. Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context. In general, a pattern has four essential elements:
Design Patterns:Elements of Rousable Object-Orientod Software 1.The pattern name is a handle we can use to describe a design problem,its solutions, and c onsequences in a word or two.Naming a pattern immediately increases our design vocabulary.It lets us design at a higher level of abstraction.Having a vocabulary for patterns lets us talk about them with our colleagues,in our documentation,and even to ourselves.It makes it easier to think about designs and to communicate them and their trade-offa toothera Findin es has been one of the hardest parts of developing our catalog. 2.The problem describes when to apply the pattern.It explains the problem and its context.It might describe specific design problems such as how to represent algorithms as objects.It might describe class or object structures that are symptomatic of an inflexible design.Sometimes the proble include a list of conditions that must be met before it makes sense to apply the pattern. 3.The solution describes the elements that make up the design,their relationships,responsibilities,and collaborations.The solution doesn't describe a particular concrete design or implementation,because a pattern is like a template that can be applied in many different situations. Instead the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case)solves it. 4.The consequences are the results and trade-ofrs of applying the pattern. Though consequences are often unvoiced when we describe design decisions, they are critical evaluating design alternatives and for understanding the costs and benefits of applying the pattern.The consequences for software often concern space and time trade-offs.They may address language and implementation issues as well.since reuse is often a factor in obiect-oriented design,the conseguences of a pattern include its impact on a syate's flexibility,extensibility,or portability.Listingt consequences explicitly helps you understand and evaluate them Point of view affects one's interpretation of what is and isn't a pattern.One person's pattern can be another person's primitive building block.For this book we have concentrated on patterns at a certain level of abstraction.Design patterns are not about designs such as linked lists and hash tables that can be encoded Nor re th plex fi esigns for an entire application or subsystem.The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. A design pattern names,abstracts,and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design The design pattern identifie he participating cla ances,their roles and collaborations,and the distribution of responsibilities.Each design pattern 3
Design Patterns: Elements of Reusable Object-Oriented Software 13 1. The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two. Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about them with our colleagues, in our documentation, and even to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others. Finding good names has been one of the hardest parts of developing our catalog. 2. The problem describes when to apply the pattern. It explains the problem and its context. It might describe specific design problems such as how to represent algorithms as objects. It might describe class or object structures that are symptomatic of an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern. 3. The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it. 4. The consequences are the results and trade-offs of applying the pattern. Though consequences are often unvoiced when we describe design decisions, they are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern. The consequences for software often concern space and time trade-offs. They may address language and implementation issues as well. Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system's flexibility, extensibility, or portability. Listing these consequences explicitly helps you understand and evaluate them. Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern can be another person's primitive building block. For this book we have concentrated on patterns at a certain level of abstraction. Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Nor are they complex, domain-specific designs for an entire application or subsystem. The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. Each design pattern
Design Patterns:Elements of Rousable Object-Oriented Software tocuses 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 c its use.since we must eventually imple our designs,a design pattern also provides sample C++and (sometimes)Smalltalk code to illustrate an implementation. Although design patterns describe obiect-oriented designs.they are based on practical solutions that have been implemented in mainstream obiect-oriented ming languages like Smalltalk and C++rather than procedural se (Pascal,C,Ada) dynam -oriented languages (CI 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 ot 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, "Encapsulation,"and "Polymorphism."Similarly,some of our patterns are supported directly by the less common obiect-oriented languages.CLOS has multi-methods, for example,which lessen the need for a pattern such as Visitor (page 366).In tact,thereare nough ditterences betwee kand C+ patterns can be expr sed more easily ino language than the other.(See Iterate (289)for an examp1e. Design Patterns in Smalltalk MVC The Model/view/Controller (MVC)triad of classes [KP88]is used to build user interfaces in smalltalk-80.Looking at the design patterns inside Mvc should help You mear n 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 obiects together.MVC decouples them to increase flexibility and reuse. MVC decouples views and models by establishing a subscribe/notify protocol between hem A view ens that its appear ce reflects the state of the mode 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 controllera for simplicity.)The model contains some data values,and the views defining
Design Patterns: Elements of Reusable Object-Oriented Software 14 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," "Encapsulation," 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 366). 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 (289) for an example.) Design Patterns in Smalltalk MVC The Model/View/Controller (MVC) triad of classes [KP88] is used to build user interfaces in Smalltalk-80. 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
Design Patterns:Elements of Rousable Object-Orientod Software spreadsheet,histogram,and pie chart display these data in various ways.The model c unicates with its views when its values change,and the views communicate with the model to access these values. views window 五 windo ☐window ■ a b c b x603010 y503020 z801010 a=50 model Taken at face value,this example reflects a design that decouples views from models.But the design is applicable to a more general problem:decoupling objects so that changes to one can affect any number of others without requiring the changed obiect to know details of the others.This more general design is described by the Observer (page 326)design pattern. Another feature of Mvc is that views can be nested.For example,a control panel of buttons might be implemented as a complex view containing nested button views The user interface for an object inspector can consist of nested views that may be reused in a debugger.MVC supports nested viens with the Compositeview class, a aubclass of View.Compositeview obiects act iuat like View obiects:a composite view can be used wherever a view can be used,but it also contains and manages nested views Again,we could think of this as a design that lets us treat a composite view just like we treat one of its components.But the design is applicable to a more general problem,which occurs whenever we want to group objects and treat the group like an individual object.This more general design is described by the 15
Design Patterns: Elements of Reusable Object-Oriented Software 15 spreadsheet, histogram, and pie chart display these data in various ways. The model communicates with its views when its values change, and the views communicate with the model to access these values. Taken at face value, this example reflects a design that decouples views from models. But the design is applicable to a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. This more general design is described by the Observer (page 326) design pattern. Another feature of MVC is that views can be nested. For example, a control panel of buttons might be implemented as a complex view containing nested button views. The user interface for an object inspector can consist of nested views that may be reused in a debugger. MVC supports nested views with the CompositeView class, a subclass of View. CompositeView objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views. Again, we could think of this as a design that lets us treat a composite view just like we treat one of its components. But the design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. This more general design is described by the
Design Patterns:Elements of Rousable Object-Oriented Software Composite (183)design pattern.It lets you create a class hierarchy in which some subclasses derine primitive objects (e.g.,Button)and other classes define mposite objects (Co siteView】 le the primitives into more objects. MVc also lets you change the way a view responds to user input without changing its visual presentation.You might want to change the way it responds to the keyboard, for example,or have it use a pop-up menu instead of command keys.MVC encapsulates the response mechanism in a Controller object.There is a class hierarchy of control lers,making it easy to create a new co ller as a variation on an existing one. 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 ditterent 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(349)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,or when has structures that you want to encapsulate. MVC uses other design patterns,such as Factory Method(121)to specify the default controller class for a view and Decorator (196)to add scrolling to a view.But the main relationships in MVC are given by the observer,Composite,and strategy design patterns. Describing Design Patterns How do we describe design patterns?Graphical notations,while important and useful,aren't sufticient.They simply capture the end product of the design process as relationships between classes and objects.To reuse the design,we must also record the decisions,alternatives,and trade-offs that led to it. Concrete ples are important too,bece hey help you see the design in action. We describe design patterns using a consistent 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 16
Design Patterns: Elements of Reusable Object-Oriented Software 16 Composite (183) design pattern. It lets you create a class hierarchy in which some subclasses define primitive objects (e.g., Button) and other classes define composite objects (CompositeView) that assemble the primitives into more complex objects. MVC also lets you change the way a view responds to user input without changing its visual presentation. You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. MVC encapsulates the response mechanism in a Controller object. There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one. 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 (349) 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 (121) to specify the default controller class for a view and Decorator (196) to add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns. 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 relationships 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 consistent 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