面向可维护性的设计模式（哈工大软件构造）

  在软件的发展周期中，随着时间的变化，软件的复杂度会得到很大的增长，我们需要对代码的维护付出很大的精力，以便其能适应各种变化，具有良好的可维护性，在之后的维护过程中以较小的成本对软件进行维护。
  在第五章，我们学习了如何使软件具有较高的可维护性，并介绍了几种面向可维护性的设计模式，在此进行总结和分享。
  首先介绍一种创造型模式（Creational Patterns）:

工厂方法模式（Factory Method Pattern）

  解决的问题：解决了接口选择的问题。
  解决方法：通过工厂父类定义创建对象的公共接口，而子类则负责生成具体的对象。
  优点：用户只需要知道工厂的名称就可以得到对应的产品，不需要关注产品的生产细节。并且在添加新的产品时，只需要添加对应的具体产品和具体工，满足开闭原则。
  缺点：每增加一个产品，需要对应的增加两个类，提高了系统的复杂度。
  组成成分：
1. 抽象工厂（Abstract Factory）：提供创建产品的接口，即最高级的“构造函数”；
2. 具体工厂（Concrete Factory）：实现了抽象工厂的接口，完成具体产品的创建；
3. 抽象产品（Abstract Product）：定义了产品基本性质的接口。
4. 具体产品（Concrete Product）：实现了抽象产品定义的接口，有具体工厂来创建，与具体工厂一一对应。
  处理方式：用户通过具体的工厂生成具体的产品，对客户端隐藏了产品的构建方式。
  具体实现后的UML图如下：

抽象工厂模式（Abstract Factory Pattern）

  与抽象方法模式所区别的是，抽象方法模式主要用于产生一个产品，而抽象工厂模式负责产生一族相互之间有关联的产品。
  解决的问题：在工厂方法模式的基础上，对于一系列相互关联的产品创建方式繁琐的问题。
  解决方法：通过工厂父类定义创建对象的公共接口，而子类则负责生成具体的对象。
  优点：用户只需要知道工厂的名称就可以得到对应的产品，不需要关注产品的生产细节。并且在添加新的产品族时，只需要添加对应的具体产品和具体工，满足开闭原则。除此之外，由于抽象工厂可以产生一族产品，故每个工厂类可以创建同一族但是完全不同类型的两个产品。
  缺点：当产品族中需要增加新的产品时，所有的工厂类都要进行修改。即，抽象工厂模式对于新的产品族，满足开闭原则，只需要添加新的具体工厂对产品进行组合。但对新的产品却不满足开闭原则，需要对所有的类进行更改。
  组成成分：
1. 抽象工厂（Abstract Factory）：提供创建产品的接口，即最高级的“构造函数”；
2. 具体工厂（Concrete Factory）：实现了抽象工厂的接口，完成对多种具体产品的创建；
3. 抽象产品（Abstract Product）：定义了产品基本性质的接口。
4. 具体产品（Concrete Product）：实现了抽象产品定义的接口，具体工厂来创建，与具体工厂一一对应。
  处理方式：用户通过具体的工厂生成具体的产品族，对客户端隐藏了产品的构建方式。
  具体实现后的UML图如下：

  下面介绍一种结构型模式（Structural Pattern）：

代理模式（Proxy Pattern）

  解决的问题：当实体对象具有隐私性、敏感性，或者访问代价大等特性时，需要使用代理模式进行高效访问。
  解决方法：通过以一个新的对象类作为传递实体，对另一个对象进行访问控制。
  优点：可以通过远程代理（Remote Proxy）、虚拟代理（Virtual Proxy）、保护型代理（Protection Proxy）达到信息缓存、替换实体、存取控制等特质。代理模式也起到了分离客户端和目标对象的功能，降低了系统的耦合度。
  缺点：由于代理对象，可能会延迟处理速度，增加系统的复杂度。
  组成成分：
1. 抽象主体（Subject）：通过接口或抽象类定义了主体的性质；
2. 真实主体（Real Subject）：实现了抽象主体，是代理类所代理的真实对象；
3. 代理类（Proxy）：提供了与具体主体相同的接口，一般内部含有对真实主体的引用，可以通过代理类访问、控制或扩展真实主体的功能。
  处理方式：用户端可以按照真实主体的方式对代理类进行调用，所有的处理方式均在代理类中实现。注意，代理模式的访问控制往往发生在对象级别上，通过在代理类中维护一个真实主体的对象达到代理的功能。
  具体实现后的UML图如下：

  最后介绍两种行为型模式（Behavioral Pattern）：

观察者模式（Proxy Pattern）

  解决的问题：简洁设置了一个对象和其他多个对象之间有着较为密切关系时复杂的组合关系。
  解决方法：通过面向对象的技术，弱化依赖关系。当被观察者（一）发生变化时，会通知给每一个观察者（多）。
  优点：降低了具有关系的两个对象之间的耦合度，并在两者之间建立了一种触发机制。
  缺点：观察者和被观察者之间的耦合没有完全解除，并且会由于特殊的原因产生“循环引用”。并且当观察者较多时，会延缓系统运行速度。并且观察者只能知道被观察者发生了变化，但不能具体到哪一类变化。
  组成成分：
1. 抽象目标（Subject）：即被观察者的抽象类，其中一般需要维护一个观察者的列表，以及对于这个列表的维护操作，如添加、删除等操作。
2. 具体目标（Concrete Subject）：实现了抽象目标接口。
3. 抽象观察者（Observer）：即观察者的接口，其中一般需要包含一个更新自身的抽象方法，在“观察到”被观察者变化时调整自身状态使用。
4. 具体观察者（Concrete Observer）：实现了抽象观察者。
  具体实现后的UML图如下：

  处理方式：这四个部分的调用顺序如下：
1. 客户端或其他任何地方的变化引起了被观察者的变化。
2. 被观察者调用自身的notifyObserver方法通知自己列表中的所有观察者。
3. 所有的观察者接收到信息后（在notifyObserver方法中被引用调用了自己的response方法），更新自己的状态。
  Java中已经专门定义了Observable接口和Observer接口用于实现观察者模式，被观察者要实现Observable接口，观察者要实现Observer接口。 两个接口的主要代码如下：

访问者模式（Visitor Pattern）

  解决的问题：解决了一个类针对不同的元素所进行的操作不同的问题。
  解决方法：将作用于不同类的操作封装成类，为数据结构中的每个元素提供多种访问方式，将对数据的操作和数据结构进行分离。
  优点：有很高的扩展性、复用性、灵活性，并且满足单一职责原则，将相关的行为封装在一起，每一个访问者有着单一的功能。
  缺点：对于新的被访问类不满足开闭原则，一旦加入新的被访问类，就需要改变所有的访问者的代码。并且访问者类不满足依赖倒置原则，内部依赖了具体的元素类。
  组成成分：
1. 抽象访问者（Visitor）：一个访问具体元素的接口，以参数多态的方式，为每个具体的元素类提供了一个访问操作。
2. 具体访问者（Concrete Visitor）：实现了抽象访问者接口。
3. 抽象元素（Element）：一个被访问的元素的接口，一般包含有accept方法，参数为一个Visitor类型的对象，表示接受这个访问者进行访问。
4. 具体元素（Concrete Element）：实现了抽象元素接口，其中的accept方法一般都是visitor.visit(this) 的形式。
5. 对象结构（Object Structure）：其中维护着元素类型的容器，如列表或映射等等，提供了让访问者访问其中所有对象的操作。
  处理方式：通过将具体操作封装成类，设计为访问者类，通过在具体元素自身内调用accept方法传入对应的访问者（操作类），以达到访问该类的目的。
  具体实现后的UML图如下：

参考博客：

1. 软件设计模式概述
2. 菜鸟教程：设计模式