设计模式复习重点之八大模式

工厂方法模式（虚拟构造器模式多态工厂模式）女娲照人（黑白黄三类）

定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。到子类中完成，即由子类来决定究竟应该实例化（创建）哪一个类。

参与者：

工厂角色（Creator）

声明工厂方法，返回一个产品。

真实的工厂（Concrete Creator）

实现工厂方法，由客户调用，返回一个产品的实例。

产品角色（Product）

定义产品的接口。

真实的产品（Concrete Product）

实现接口产品角色的类。

优点：1，基于工厂角色和产品角色的多态性设计。所有具体工厂类都具有同一抽象父类。

产品。3工厂方法模式是典型的解耦框架。高层模块只需要知道产品的抽象类，其他的实现类都不用关心，符合迪米特法则，也符合依赖倒置原则，也符合里氏替换原则。

缺点：添加新产品时，需编写新的具体产品类，还要提供与之对应的具体工厂类。

适用性：

类不知道自己要创建哪一个对象

类用它的子类来指定创建哪个对象

客户需要清楚创建了哪一个对象

案例一：设计一个连接邮件服务器的框架，有三种网络协议可供选择：POP3，IMAP，HTTP，我们就可以把这三种连接方法作为产品类。定义一个接口如IConnectMail，然后定义对邮件的操作方法，用不同的方法实现三个具体的产品类（也就是连接方式），再定义一个工厂方法，按照不同的传入条件，选择不同的连接方式。

案例二：异构项目中，通过WebService与一个非Java的项目交互，虽然WebService号称是可以做到异构系统的同构化，但是在实际的开发中，还是会碰到很多问题，如类型问题，WSDL文件的支持问题等等。可以从WSDL中产生的对象都认为是一个产品，然后由一个具体的工厂类进行管理，减少与外围系统的耦合。

案例三：在数据库开发中，连接数据库，数据库从MySQL切换到Oracle，需要改动的地方就是切换一下驱动名称，其他的都不需要修改。

抽象工厂模式（kit模式）

女娲造人忘记给人类定义了性别，那怎么办？抹掉重来，从头开始建立所有事物，使用的物品和设备还是原来的黄土和八卦炉，但是现在需要在不同的人种之中加入性别，于是把八卦炉一份为二，分为女性八卦炉和男性八卦炉。

定义：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。

1、提供一系列相互依赖对象的创建工作

2、封装对象常规的创建方法（new）（变化点在“对象创建”，因此就封装“对象创建”。面向接口编程

——依赖接口，而非依赖实现）

3、提供统一调用数据访问方法的方式

4、避免调用数据访问方法和具体对象创建工作的紧耦合

提供一个创建一系列相关或相互依赖对象的接口，无需指定它们具体的类

抽象工厂设计模式中各个对象的主要功能、职责：

2、用实体工厂生产实体产品

3、用抽象产品提供实体产品访问接口

4、用实体产品实现自己的功能

参与者：

抽象工厂（Abstract Factory）

声明生成抽象产品的方法。

具体工厂（Concrete Factory）

执行生成抽象产品的方法，生成一个具体的产品。

抽象产品（Abstract Product）

为一种产品声明接口。

具体产品（Product）

定义具体工厂生成的具体产品的对象，实现产品接口。

客户（Client）

我们的应用程序，使用抽象产品和抽象工厂生成对象

优点：1隔离了具体类的生成，使得客户不需要知道什么被创建了。2当一个产品族中的多个对象被设计

3符合开放封闭原则

缺点：添加新的产品对象时，难以扩展抽象工厂以便生产新种类的产品。

适用性：

系统需要屏蔽有关对象如何创建，如何组织和如何表示

系统需要由关联的对象来构成

有关联的多个对象需要一起应用并且它们的约束是强迫的（不可分离）

你想提供一组对象而不显示它们的实现过程，只显示它们的接口

案例一：一个文本编辑器和一个图片处理器，都是软件实体，但是*nix下的文本编辑器和Windows下的文本编辑器虽然功能和界面都相同，但是代码实现是不同的，图片处理器也有类似情况。也就是具有了相同的约束条件：操作系统类型。于是我们可以使用抽象工厂模式，产生不同操作系统下的编辑器和图片处理器。

案例二：一个应用，需要在三个不同平台（Windows 、*nix、Android）上运行，你会怎么设计？分别设计三套不同的应用？非也，通过抽象工厂模式屏蔽掉操作系统对应用的影响。三个不同操作系统上的软件功能、应用逻辑、UI都应该是非常类似的，唯一不同的是调用不同的工厂方法，由不同的产品类去处理与操作系统交互的信息。

适配器模式

适配（转换）的概念无处不在

适配，即在不改变原有实现的基础上，将原来不兼容的接口转换为兼容的接口。

即能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口

新买的MP3播放器，只提供了USB接口充电的方式，需要为目前所配备的充电器装上一个USB接口的转换器，才可以解决这个问题。

定义:将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两

参与者:

目标抽象类（Target）(客户端所期待的接口，目标可以是具体的或者抽象的类或者是接

口)

定义客户要用的特定领域的接口

适配器：公接口（Adapter）（包装Adaptee对象把源接口变为目标接口）

调用另一个接口，作为一个转换器

适配器：母接口（Adaptee）（需要适配的类）

定义一个接口，适配器需要接入

客户调用类（Client）

协同对象符合适配器适配器（公接口）

优点：可以统一对象的访问接口。但其前提是不能或不想修改原来的适配器母接口。

缺点：客户调用可能需要变动，这时，修改起来比较麻烦。

适用性：

对象需要利用现存的并且接口不兼容的类

需要创建可重用的类以协作其他接口不一定兼容的类

需要使用若干个现存的子类，但又不想派生这些子类的每一个接口。

最好不要在详细设计阶段不要考虑它，它不是为了解决还处在开发阶段的问题，而是解

决正在服役的项目问题。

适配器模式是一个补救模式。

组合模式

将对象组合成树形结构表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

参与者：

部件抽象接口（Component）

为组合的对象声明接口。

某些情况下，实现从此接口派生出所有类共有的默认行为。定义一个接口可以

访问及管理它的多个子部件。如果必要，也可以在递归结构中定义一个接口访

问它的父节点，并且实现它。

组合类（Composite）

定义有子节点（子部件）的部件行为。存储子节点（子部件）。

在Component部件抽象接口中实现与子部件相关的操作。（增，删）

叶部件（Leaf）

在组合中表示叶节点对象，叶节点没有子节点。定义组合中原接口对象的行为。

客户应用程序（Client）

通过部件抽象接口控制组合部件的对象。

组合模式——透明的组合模式

透明模式的好处：

基本遵循了依赖倒置原则，方便系统进行扩展。

优点：可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次，使得增加新部件也更容易，提供

缺点：使得设计变得更加抽象。

适用性：

想表示一个对象整体或部分层次。

想让客户能够忽略不同对象的层次的变化。

对象的结构是动态的并且复杂程度不一样，但客户需要一致地处理它们。

维护和展示部分-整体关系的场景，如树形菜单、文件和文件夹管理。

装饰模式

定义：动态地给一个对象添加一些额外的职责，就增加对象功能来说，装饰模式相比生成子类更为灵活。

参与者：

部件（Compontent）

定义对象的接口，可以给这些对象动态增加职责（方法）。

具体部件（Concrete Compontent）

定义具体的对象，装饰抽象类可以给它增加额外的职责（方法）。

装饰抽象类（Decorator）

维护一个内有的部件，并且定义一个与部件接口一致的接口。继承Compontent

类从外类来扩展Compontent类。

具体装饰对象（Concrete Decorator）

具体的装饰对象，（给Concrete Compontent类）给内在的具体部件对象增加具

体的职责（方法）

优点：1提供了比静态继承更好的柔韧性，允许开发一系列的功能类来代替增加对象的行为，这既不会污染原来对象的源码，还能使代码更容易编写，使类更具扩展性，因为变化都是由新的装饰类来完成的。2还可以建立连接的装饰对象关系链。3可以替代继承，解决我们类膨胀的问题。继承是静态地给类增加功能，而装饰模式则是动态地增加功能。

缺点：1装饰链不易过长，太长会使系统花费较长时间用于初始化对象，同时信息在链中的传递弛会浪费太多的时间。2如果原来的对象接口发生变化，它所有的装饰类都要修改以匹配它的变化。3派生子类会影响对象的内部，而一个Decorator只会影响对象的外表。

适用性：

需要扩展一个类的功能，或给一个类增加附加功能。

需要动态地给一个对象增加功能，这些功能可以再动态地撤销。

需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。

代理模式

定义：为其他对象提供一个代理以控制对这个对象的访问。

当客户向代理对象第一次提出请求时，代理实例化真实的对象，并且将请求传给它，以后所有的客户请求都经由代理传给封装了的真实对象。

参与者：

抽象实体接口（Subject）

定义实体和代理的公用接口，这样任何使用RealSubject实体的地方就可以使用

Proxy代理了。

实体（RealSubject）

定义一个接口，Adapter需要接入（定义Proxy所代表的真实实体）

代理（Proxy）

保存一个引用使得代理可以访问实体

提供一个与Subject的接口相同的接口，使得代理可以用来替代实体

控制对实体的存取，并可能负责创建和删除它

其他功能：

–Remote Proxy : 对请求及其参数进行编码，先实体发送已编码的请求

–Virtual Proxy : 缓存实体的附加信息，以延迟对它的访问

–Protection Proxy : 检查调用者是否具有需要的访问权限

优点：1远程代理可以掩蔽对象由网络生成的过程，系统的速度会加快；2对于大图片的加载，虚拟代理可以让加载在后台进行，前台的代理对象使得整体运行速度得到优化；保护代理可以验证对象的引用权限。缺点：请求的处理速度会变慢，并且实现代理模式需要额外的工作。

适用性：

虚拟代理：代理不会生成一个真实的耗费代理，直到非常有必要时（首次有请求时，用

来存放花费大（实例化要很长时间）的真实对象。

远程代理：本地代理对象控制一个远程的对象。

安全代理：代理检查调用真实对象所需要的权限。

聪明代理：当调用真实的对象时，代理处理另外一些事。

观察者模式

定义：对象间的一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。

参与者

观察者（Observer）：

定义一个更新接口，在一个被观察对象改变时应被通知。

具体观察者（Concrete Observer）：

维护一个对具体被观察对象的引用。

储存状态，状态需与具体被观察对象保持一致。

实现观察者更新接口以保持其状态与具体被观察对象一致。

被观察对象（Subject）：

了解其多个观察者，任意数量的观察者可以观察一个对象。

提供一个接口用来绑定及分离观察者对象

具体被观察对象（Concrete Subject）：

储存具体观察者有兴趣的状态。

当其状态改变时发送一个通知给其所有的观察者对象。

优点：抽象了被观察对象与观察者对象的连接，提供了广播式的对象间通信，并且容易增加新的观察者对缺点：对象间的关系难以理解，在某种情况下会表现低效能。

适用性：

对一个对象的变化请求需要其他对象也变化，并且其他要变化对象的数量不明确。

一个对象需要通知其他对象而不需要掌握其他对象的识别方法。

案例一：猫鼠游戏：夜里猫叫一声，家里的老鼠撒腿就跑，同时也吵醒了熟睡的主人，这个场景中，猫就是被观察者，老鼠和人则是观察者。

案例二：广播收音机：电台在广播，你可以打开一个收音机，或者两个收音机来收听，电台就是被观察者，收音机就是观察者。

案例三：ATM取钱：在ATM机器上取钱，多次输错密码，卡就会被ATM吞掉，吞卡动作发生的时候，会触发那些事件呢？第一，摄像头连续快拍；第二，通知监控系统，吞卡发生；第三，初始化ATM屏幕，返回最初状态。一般前两个动作都是通过观察者模式来完成的，后一个动作是异常来完成的。

策略模式

我们打算去机场乘飞机，可以选择很多交通方法（摩托车、公共汽车、出租车），我们可以根据时间要求和乘车费用，而采用不同的策略。

定义：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。其让算法独立于使用它的客户而变化。

参与者：

抽象策略类（Strategy）

定义一个公共的接口给所有支持的算法。场景使用这个接口调用具体策略类定

义的算法。

具体策略类（Concrete Strategy）

调用抽象策略类接口，实现具体的算法。

场景（Context）

用具体策略类对象配置其执行环境。

维护一个对抽象策略类的引用实例。

可以定义一个接口供抽象策略类存取其数据。

优点：1提供了替代派生的子类，并定义类的每个行为，剔除了代码中条件的判断语句，使得扩展和结合新的行为变得更容易，根本不需要变动应用程序。2可以避免使用多重条件转移语句，系统变得更加灵活。缺点：1会产生很多子类。2所有的策略类都需要对外暴露。

适用性：

多个类的分别只是在于行为不同。

需要对行为的算法作很多变动。

客户不知道算法要使用的数据。

工厂方法模式：一个抽象产品类，可以派生出多个具体产品类。一个抽象工厂类，可以派生出多个具体工厂类。每个具体工厂类只能创建一个具体产品类的实例。

抽象工厂模式：多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。一个抽象工厂类，可以派生出多个具体工厂类。每个具体工厂类可以创建多个具体产品类的实例。

区别：工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。

工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。

工厂创建一种产品，抽象工厂创建的是一组产品，是一个产品系列。这里要注意的是“系列”的意思，也就是说，抽象工厂创建出的一组产品是成套的。

当你发现，有一个接口可以有多种实现的时候，可以考虑使用工厂方法来创建实例。

当你返现，有一组接口可以有多种实现方案的时候，可以考虑使用抽象工厂创建实例组。

工厂方法模式：一个工厂只能出现一类产品，工厂及产品有多种实现。

抽象工厂模式：一个工厂可以生产多种产品，每种产品有多种实现。

BUILDER:生成一种产品，但是这种产品需要多个功能完成，这时使用BUILDER模式。