软件构造复习(2)——面向可维护性的设计模式

复习完面向复用性的设计模式之后，理应就是面向可维护性的设计模式了 ，个人感觉面向可维护性的设计模式比面向复用性的设计要简单一些。但是原理的话都差不多，无非就是利用delegation等方式来达成目的。

面向可维护性的设计模式主要有 Factory method pattern(工厂方法模式)、Abstract factory pattern(抽象工厂模式）、Proxy(代理模式）、Observer(观察者模式)、Visitor（访问者模式)

1.Factory method pattern(工厂方法模式)

工厂方法模式的意义是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。

问题:当client不知道/不确定要创建哪个具体类的实例，或者不想在client代码中指明要具体创建的实例时，用工厂方法。
解决方法：定义一个用于创建对象的接口，让该接口的子类型来决定实例化哪一个类，从而使一个类的实例化延迟到其子类。

静态工厂方法模式

静态工厂方法既可以在ADT内部实现，也可以构造单独的工厂类。

静态工厂方法相比通过构造器 器(new)构建对象：
1. 静态工厂方法 静态工厂方法 可 具有 指定 的 名称
2. 不必在每次调用的时候都创建新对象 不必在每次调用的时候都创建新对象
3. 可以返回原返回类型的任意子类型

工厂方法的优势：
工厂方法模式是简单工厂模式的衍生，解决了许多简单工厂模式的问题。首先完全实现’开-闭 原则’，实现了可扩展。其次更复杂的层次结构，可以应用于产品结果复杂的场合。

工厂方法劣势:
每增加一种产品就需要增加一个新的 工厂 子类

2.Abstract Factory 抽象工厂模式

提供接口以 创建一组相关/ 相互依赖的对象 ，但不需要指明其具体实现类。

比如

一个UI ，包含多个窗口控件，这些 控件的组合在不同的OS中实现不同
一个智能房屋的设备管理系统，要控制多个设备，这些设备的制造商各有不同，
控制接口有差异

解决方法:（以UI为例)
①抽象出一个抽象工厂接口，里面有两个接口分别负责创建Window 和 ScrollBar.
②需要为Window和ScrollBar分别抽象出接口，并且需要实现这两个接口，分别定义不同的对象。
③根据不用的UI，实现不同的Window和ScrollBar组件的组合。即继承我们定义的抽象工厂类，实现里面具体的方法。具体的方法根据具体的UI创建不同的Window和ScrollBar。
如图所示。

抽象工厂方法:
创建的不是一个完整产品，而是“产品族”（遵循固定搭配规则的多类产品的实例），得到的结果是：多个不同产品的object ，各产品创建过程对client 可见，但“搭配”不能改变。

本质上，Abstract Factory 是把多类产品的factory method组合在一起

注意:搭配是不能改变的，在产品族里面，不同的产品组件是唯一确定的，不可改变。这也是抽象工厂和方法和直接使用多个工厂方法创建的区别，直接使用多个工厂方法创建，可能会因为不知道搭配而用错工厂

3.Proxy 代理模式

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

组成:
抽象角色:通过接口或抽象类声明真实角色实现的业务方法。
代理角色:实现抽象角色，是真实角色的代理，通过真实角色的业务逻辑方法来实现抽象方法，并可以附加自己的操作。
真实角色:实现抽象角色，定义真实角色所要实现的业务逻辑，供代理角色调用。

具体实例:主要是解决每次创建都需要磁盘装载的问题，使用代理，只有当需要进行磁盘装载的时候才进行磁盘装载。

Proxy vs. Adaptor

Adapter: structural pattern

目的：消除不兼容，目的是B 以客户端期望的统一的方式与A 建立起联系。

Proxy: behavioral pattern

目的：隔离对复杂对象的访问，降低难度/ 代价，定位在“访问/ 使用行为”

4. Observer 观察者模式

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

解决方法:
①一种“发布-订阅”形式，发布方的变化，会通知订阅方
②订阅方在发布方注册
③通过接口分离两者
④维护订阅者列表
⑤定义update的协议
⑥维护数据，修改后通知订阅者
⑦得到通知后，修改自身的状态

观察者模式

优势：
主体( 被观察者) 和观察者之间松耦合，主体不需要关注观察者
动态的增加和删除观察者

劣势
主体需要存储观察者列表可通过
在update() 中增加参数来观察多个主体
触发机制

5.Visitor访问者模式

①对特定类型object 的特定操作(visit) ，在运行时将二者动态绑定到一起，该操作可以灵活更改，无需更改被visit
②将数据和作用于数据上的某种/些特定操作分离开来。
③为ADT 预留一个将来可扩展功能的“接入点”，外部实现的功能代码可以在不改变ADT 本身的情况 下在需要时通过delegation 接入ADT

涉及角色
1.Visitor 抽象访问者角色，为该对象结构中具体元素角色声明一个访问操作接口。该操作接口的名字和参数标识了发送访问请求给具体访问者的具体元素角色，这样访问者就可以通过该元素角色的特定接口直接访问它。
2.ConcreteVisitor.具体访问者角色，实现Visitor声明的接口。
3.Element 定义一个接受访问操作(accept())，它以一个访问者(Visitor)作为参数。
4.ConcreteElement 具体元素，实现了抽象元素(Element)所定义的接受操作接口。
5.ObjectStructure 结构对象角色，这是使用访问者模式必备的角色。它具备以下特性:能枚举它的元素;可以提供一个高层接口以允许访问者访问它的元素;如有需要，可以设计成一个复合对象或者一个聚集(如一个列表或无序集合)。

Visitor vs Iterator

Iterator: behavioral pattern
迭代器：以遍历的方式访问集合数据而无需暴露其内部表示，将“遍历”这项功能delegate到外部的iterator对象。

Visitor: behavioral pattern
在特定ADT上执行某种特定操作，但该操作不在ADT内部实现，而是delegate到独立的visitor对象，客户端可灵活扩展/改变visitor的操作算法，而不影响ADT

Strategy vs Visitor

二者都是通过delegation

但是Visitor强调是的外部定义某种对ADT的操作，该操作于ADT自身关系不大（只是访问ADT），故ADT内部只需要开放accept(visitor)即可，client通过它设定visitor操作并在外部调用。

而Strategy则强调是对ADT内部某些要实现的功能的相应算法的灵活替换。这些算法是ADT功能的重要组成部分，只不过是delegate到外strategy类而已。

区别：visitor是站在外部client的角度，灵活增加对ADT的各种不同操
作（哪怕ADT没实现该操作），strategy则是站在内部ADT的角度，
灵活变化对其内部功能的不同配置。