学习设计模式笔记（二）部分总结

（7）生成器模式：创建型

将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示，这样的设计模式被称为建造者模式。



建造者（Builder）角色：给出一个抽象接口，以规范产品对象的各个组成成分的建造。一般而言，此接口独立于应用程序的商业逻辑。模式中直接创建产品对象的是具体建造者（ConcreteBuilder）角色。具体建造者类必须实现这个接口所要求的方法：一个是建造方法，另一个是结果返还方法。

具体建造者（Concrete Builder）角色：担任这个角色的是于应用程序紧密相关的类，它们在应用程序调用下创建产品实例。这个角色主要完成的任务包括：

实现Builder角色提供的接口，一步一步完成创建产品实例的过程。

在建造过程完成后，提供产品的实例。

指导者（Director）角色：担任这个角色的类调用具体建造者角色以创建产品对象。导演者并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者对象。

产品（Product）角色：产品便是建造中的复杂对象。

指导者角色是于客户端打交道的角色。导演者角色将客户端创建产品的请求划分为对各个零件的建造请求，再将这些请求委派给具体建造者角色。具体建造者角色是做具体建造工作的，但却不为客户端所知。

生成器模式的本质：分离整体的构建算法和部件构造。优点：松散耦合，可以很容易的改变产品的内部表示。

（8）原型模式：创建型

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

Prototype原型模式是一种创建型设计模式，Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。



客户（Client）角色：客户端类向原型管理器提出创建对象的请求。[1]

抽象原型（Prototype）角色：这是一个抽象角色，通常由一个C#接口或抽象类实现。此角色给出所有的具体原型类所需的接口。在C#中，抽象原型角色通常实现了ICloneable接口。

具体原型（Concrete Prototype）角色：被复制的对象。此角色需要实现抽象的原型角色所要求的接口。

原型管理器（Prototype Manager）角色：创建具体原型类的对象，并记录每一个被创建的对象。

原型模式优点，对客户端隐藏具体的实现类型；在运行时动态改变具体的实现类型。本质：克隆生成对象。

（9）中介者模式：行为型

定义一个中介对象来封装系列对象之间的交互。中介者使各个对象不需要显示地相互引用，从而使其耦合性松散，而且可以独立地改变他们之间的交互。



1) 抽象中介者（Mediator）角色：抽象中介者角色定义统一的接口用于各同事角色之间的通信。

2) 具体中介者（Concrete Mediator）角色：具体中介者角色通过协调各同事角色实现协作行为。为此它要知道并引用各个同事角色。

3) 同事（Colleague）角色：每一个同事角色都知道对应的具体中介者角色，而且与其他的同事角色通信的时候，一定要通过中介者角色协作。

优点：松散耦合，集中控制交互，多对多变成一对多。缺点：过度集中化。本质：封装交互

（10）代理模式：结构型

代理模式的定义：为其他对象提供一种代理以控制对这个对象的访问。在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。



抽象角色：声明真实对象和代理对象的共同接口； 

代理角色：代理对象角色内部含有对真实对象的引用，从而可以操作真实对象，同时代理对象提供与真实对象相同的接口以便在任何时刻都能代替真实对象。同时，代理对象可以在执行真实对象操作时，附加其他的操作，相当于对真实对象进行封装。 

真实角色：代理角色所代表的真实对象，是我们最终要引用的对象。

代理模式本质：控制对象访问。

（11）观察者模式：行为型

在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实现事件处理系统。



观察者：（Observer）将自己注册到被观察对象（Subject）中，被观察对象将观察者存放在一个容器（Container）里。

被观察

被观察：对象发生了某种变化（如图中的SomeChange），从容器中得到所有注册过的观察者，将变化通知观察者。

优点：观察者模式实现了观察者和目标之间的抽象耦合，实现了动态联动，可以支持广播通信。缺点：可能引起无谓的操作。

本质：触发联动

（12）命令模式：行为型

  将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。


Command：

定义命令的接口，声明执行的方法。

ConcreteCommand：

命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

Receiver：

接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

Invoker：

要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

Client：

创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。

优点：松散耦合，动态控制，良好的扩展性。本质：封装请求