《设计模式》读书笔记_A

title：<Design Patterns Elements of Reusable Object-Oriented Software>

author: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

version: 1st （1995）

Preface: 

This book assumes you are reasonably proficient in at least one object-oriented programming language, and you should have some experience in object-oriented design as well. 

 This isn't an advanced technical treatise either. It's a book of design patterns that describes simple and elegant solutions to specific problems in object-oriented software design. Design patterns capture solutions that have developed and evolved over time. 

A word of warning and encouragement: Don't worry if you don't understand this book completely on the first reading... We hope you'll find yourself referring to it again and again for design insights and for inspiration.

This book has two main parts. The first part (Chapters 1 and 2) describes what design patterns are and how they help you design object-oriented software. It includes a design case study that demonstrates how design patterns apply in practice. The second part of the book (Chapters 3, 4, and 5) is a catalog of the actual design patterns.

Introduction:

使用OO的思想设计一个大型系统来全面的解决一个庞大问题不是一件容易的事情，真如自然语言有如此多的表达方式一样，设计出灵活、高可重用性、可扩展的OO系统并不是一件容易的事情。往往需要有很多的实际经验积累才能较好的总结出设计的方法，这些宝贵的经验就是本书所主要将要介绍的内容，它将可以帮助我们这些新手快速的学习到前人总结出来的经验，让我们站在巨人的肩膀上吧！

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.

> what is a design pattern?

   >>"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"-- Christopher Alexander

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

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

>以MVC（model-viewer-controller)中设计的几种通用pattern来具体说明本书中将要介绍的pattern是怎么样的一种形式！

MVC中主要的涉及了Observer、Composite、Strategy三种本质的pattern。

>本书中每一个pattern item是如何呈现加以介绍的：

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

   Intent

   Also Known As

   Motivation

   Applicability

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

   Participants

   Collaborations

  Consequences

 Implementation、Sample Code、Known Uses、Related Patterns

>pattern清单及其分类

>>purpose reflects what a pattern does. Patterns can have either creational, structural, or behavioral purpose. Creational patterns concern the process of object creation. Structural patterns deal with the composition of classes or objects.Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility. 

 scope specifies whether the pattern applies primarily to classes or to objects. Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static—fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic.

		Purpose
		Creational	Structural	Behavioral
Scope	Class	Factory Method	Adapter	Interpreter  Template Method
	Object	Abstract Factory  Builder  Prototype  Singleton	Adapter  Bridge  Composite  Decorator  Facade  Proxy	Chain of Responsibility  Command  Iterator  Mediator  Memento  Flyweight (195) Observer  State  Strategy  Visitor

Table 1.1:  Design pattern space

>> Creational class patterns defer some part of object creation to subclasses, while Creational object patterns defer it to another object. The Structural class patterns use inheritance to compose classes, while the Structural object patterns describe ways to assemble objects. The Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone.

How Design Patterns Solve Design Problems

( 以下部分介绍了在一个项目的完整开发流程中那些环节可以或者应该使用design pattern来指导具体的实施.同时,这一部分应该看作一个对于OO Language的高层特征的总结.这里对于OO的总结是超越语言的!十分的seminal的!!值得多读几次,反复品味!)

>Finding Appropriate Object.仅仅靠分析现实问题的模型，进而简单直接的映射到OO solution空间中的objects是不恰当的一种方法，会导致系统缺乏可扩展性。

>> Requests are the only way to get an object to execute an operation. Operations are the only way to change an object's internal data

>>  The hard part about object-oriented design is decomposing a system into objects

>> Strict modeling of the real world leads to a system that reflects today's realities but not necessarily tomorrow's.The abstractions that emerge during design are key to making a design flexible

>Determining Object Granularity 

>Specifying Object Interfaces:

>>An object's interface characterizes the complete set of requests that can be sent to the object

>> A type is a name used to denote a particular interface. We speak of an object as having the type "Window" if it accepts all requests for the operations defined in the interface named "Window." 

>>  Interfaces are fundamental in object-oriented systems. Objects are known only through their interfaces. There is no way to know anything about an object or to ask it to do anything without going through its interface. An object's interface says nothing about its implementation—different objects are free to implement requests differently. Ihterface--Dynamic binding---Polymorphism

>>  Design patterns help you define interfaces by identifying their key elements and the kinds of data that get sent across an interface

>> Design patterns also specify relationships between interfaces

>Specifying object implementations:

>> An object's implementation is defined by its class. The class specifies the object's internal data and representation and defines the operations the object can perform.

>> A mixin class is a class that's intended to provide an optional interface or functionality to other classes. It's similar to an abstract class in that it's not intended to be instantiated. Mixin classes require multiple inheritance

It's important to understand the difference between an object's class and its type.

An object's class defines how the object is implemented. The class defines the object's internal state and the implementation of its operations. In contrast, an object's type only refers to its interface—the set of requests to which it can respond. An object can have many types, and objects of different classes can have the same type.

>> It's also important to understand the difference between class inheritance and interface inheritance (or subtyping). Class inheritance defines an object's implementation in terms of another object's implementation. In short, it'sa mechanism for code and representation sharing. In contrast, interface inheritance (or subtyping) describeswhen an object can be used in place of another.

+Many of the design patterns depend on this distinction

Class inheritance is basically just a mechanism for extending an application's functionality by reusing functionality in parent classes. It lets you define a new kind of object rapidly in terms of an old one. It lets you get new implementations almost for free, inheriting most of what you need from existing classes.

However, implementation reuse is only half the story. Inheritance's ability to define families of objects with identical interfaces (usually by inheriting from an abstract class) is also important. Why? Because polymorphism depends on it.

principle of reusable object-oriented design:

Program to an interface, not an implementation

Don't declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class. You will find this to be a common theme of the design patterns in this book.

> Putting Reuse Mechanisms to Work

TBA...