设计模式：Gamma版PDF详解

需积分: 10 130 浏览量更新于2024-07-28 收藏 4.2MB PDF 举报

"Design Patterns Gamma.pdf 是一本关于设计模式的经典书籍，由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides四位作者撰写，通常称为Gang of Four（GoF）的著作。这本书深入探讨了软件工程中的设计模式，为解决常见的软件设计问题提供了可重用的解决方案。书中涵盖了创建型、结构型和行为型三大类设计模式，并通过一个文档编辑器的案例研究来阐述如何在实际项目中应用这些模式。创建型设计模式专注于对象的创建，它们提供了一种方式来封装创建对象的过程，使得客户端代码可以独立于具体类进行工作。在Design Patterns Gamma中，这包括： 1. 抽象工厂（Abstract Factory）：提供一个接口，用于创建一系列相关的或相互依赖的对象，而无需指定它们的具体类。 2. 建造者（Builder）：将复杂对象的构建与其表示分离，使同样的构建过程可以创建不同的表示。 3. 工厂方法（Factory Method）：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使类的实例化推迟到子类。 4. 原型（Prototype）：用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。 5. 单例（Singleton）：确保一个类只有一个实例，并提供一个全局访问点。结构型设计模式关注如何组合对象和类，以形成更大的结构。在书中列出的结构型模式有： 1. 适配器（Adapter）：将一个类的接口转换成客户希望的另一个接口。适配器使原本不兼容的类可以一起工作。 2. 桥接（Bridge）：将抽象部分与它的实现部分分离，使它们可以独立地变化。 3. 组合（Composite）：将对象组合成树形结构以表示“部分-整体”的层次结构。组合使得客户可以一致地对待单个对象和组合对象。 4. 装饰器（Decorator）：动态地给一个对象添加一些额外的职责。如果要扩展的对象有很多接口，装饰器提供了一种比继承更灵活的扩展方式。 5. 外观（Facade）：为一组接口提供一个一致的界面，降低系统中类的复杂性。 6. 飞重量（Flyweight）：用于减少大量相似对象的内存开销，通过共享来支持大量细粒度的对象。 7. 代理（Proxy）：为其他对象提供一种代理以控制对这个对象的访问。行为型设计模式关注对象之间的责任分配和通信。虽然在提供的部分内容中没有直接列出行为型模式，但通常包括： 1. 责任链（Chain of Responsibility）：避免将处理请求的发送者和接收者耦合在一起，使得多个对象都有机会处理请求。 2. 命令（Command）：将请求封装为一个对象，以便使用不同的请求、队列请求、或者支持可撤销的操作。 3. 解释器（Interpreter）：给定一种语言，定义它的文法表示，并提供一个解释器来处理这种语言的实例。 4. 迭代器（Iterator）：提供一种方法顺序访问聚合对象的元素，而又不暴露其底层表示。 5. 中介者（Mediator）：定义一个中介对象来简化原本复杂的对象间交互。 6. 备忘录（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后恢复对象的状态。 7. 观察者（Observer）：定义对象之间的一对多依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知并自动更新。 8. 状态（State）：允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。 9. 策略（Strategy）：定义一系列算法，把它们一个个封装起来，并使它们可以相互替换。策略让算法的变化独立于使用它的客户。 10. 模板方法（Template Method）：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 11. 访问者（Visitor）：表示一个作用于某对象结构中的各元素的操作。它可以在不改变元素的类的前提下增加新的操作。在介绍完这些模式后，书中还详细讨论了如何选择和使用设计模式，以及如何解决设计问题。此外，通过一个文档编辑器的案例研究，读者可以更好地理解如何在实际项目中应用这些设计模式，涵盖文档结构、格式化、用户界面美化、多窗口系统支持、用户操作、拼写检查和连字符化等多个方面。这些设计模式的应用不仅限于Smalltalk MVC，而是普遍适用于各种面向对象编程语言，为软件开发人员提供了强大的工具和思路，以提高代码的可维护性和可扩展性。"

Introduction

Designing object-oriented software is hard, and designing reusable object-oriented software is even harder.

You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and

inheritance hierarchies, and establish key relationships among them. Your design should be specific to the

problem at hand but also general enough to address future problems and requirements. You also want to

avoid redesign, or at least minimize it. Experienced object-oriented designers will tell you that a reusable

and flexible design is difficult if not impossible to get "right" the first time. Before a design is finished, they

usually try to reuse it several times, modifying it each time.

Yet experienced object-oriented designers do make good designs. Meanwhile new designers are

overwhelmed by the options available and tend to fall back on non-object-oriented techniques they've used

before. It takes a long time for novices to learn what good object-oriented design is all about. Experienced

designers evidently know something inexperienced ones don't. What is it?

One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse

solutions that have worked for them in the past. When they find a good solution, they use it again and again.

Such experience is part of what makes them experts. Consequently, you'll find recurring patterns of classes

and communicating objects in many object-oriented systems. These patterns solve specific design problems

and make object-oriented designs more flexible, elegant, and ultimately reusable. They help designers reuse

successful designs by basing new designs on prior experience. A designer who is familiar with such patterns

can apply them immediately to design problems without having to rediscover them.

An analogy will help illustrate the point. Novelists and playwrights rarely design their plots from scratch.

Instead, they follow patterns like "Tragically Flawed Hero" (Macbeth, Hamlet, etc.) or "The Romantic

Novel" (countless romance novels). In the same way, object-oriented designers follow patterns like

"represent states with objects" and "decorate objects so you can easily add/remove features." Once you know

the pattern, a lot of design decisions follow automatically.

We all know the value of design experience. How many times have you had design déjà-vu—that feeling

that you've solved a problem before but not knowing exactly where or how? If you could remember the

details of the previous problem and how you solved it, then you could reuse the experience instead of

rediscovering it. However, we don't do a good job of recording experience in software design for others to

use.

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.

http://lci.cs.ubbcluj.ro/~raduking/Books/Design%20Patterns/chap1fs.htm (1 of 24) [21/08/2002 19:04:16]

Introduction

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, page x]. 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:

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

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

http://lci.cs.ubbcluj.ro/~raduking/Books/Design%20Patterns/chap1fs.htm (2 of 24) [21/08/2002 19:04:16]

Introduction

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 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.)

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 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.

http://lci.cs.ubbcluj.ro/~raduking/Books/Design%20Patterns/chap1fs.htm (3 of 24) [21/08/2002 19:04:16]

Introduction

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 293) 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

Composite (163) 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 (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

http://lci.cs.ubbcluj.ro/~raduking/Books/Design%20Patterns/chap1fs.htm (4 of 24) [21/08/2002 19:04:16]

Introduction

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.

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

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 in the pattern

solve the problem. The scenario will help you understand the more abstract description of the pattern

that follows.

Applicability

What are the situations in which the design pattern can be applied? What are examples of poor

designs that the pattern can address? How can you recognize these situations?

Structure

A graphical representation of the classes in the pattern using a notation based on the Object Modeling

Technique (OMT) [

RBP+91]. We also use interaction diagrams [JCJO92, Boo94] to illustrate

sequences of requests and collaborations between objects.

Appendix B describes these notations in

detail.

Participants

The classes and/or objects participating in the design pattern and their responsibilities.

Collaborations

How the participants collaborate to carry out their responsibilities.

Consequences

How does the pattern support its objectives? What are the trade-offs and results of using the pattern?

What aspect of system structure does it let you vary independently?

Implementation

http://lci.cs.ubbcluj.ro/~raduking/Books/Design%20Patterns/chap1fs.htm (5 of 24) [21/08/2002 19:04:16]

剩余380页未读，继续阅读

ilnaij8

粉丝: 0
资源: 46

设计模式：Gamma版PDF详解

[Head.First.Design.Patterns.2004].Elisabeth.Freeman.文字版.pdf

Head.First-Design.Patterns.深入浅出-设计模式.part1.rar

Addison Wesley - Design Patterns.pdf

Head First Design Patterns(高清英文版).pdf

GoF.rar_K._design patterns_k_eckel_设计模式GOF.pdf

IT十年经典书系列英文版-Design_Patterns-Elements_of_Reusable_Object-Oriented_Software.pdf

GoF Design Patterns 中文版

Thinking in C++.pdf

Scala和设计模式.pdf

第16章 设计范式.pdf

最新资源

第16章设计范式.pdf