软考-设计模式

设计模式

软件设计模式的产生背景

“设计模式”这个术语最初并不是出现在软件设计中，而是被用于建筑领域的设计中。

1977 年，美国著名建筑大师、加利福尼亚大学伯克利分校环境结构中心主任克里斯托夫·亚历山大（Christopher Alexander）在他的著作《建筑模式语言：城镇、建筑、构造（A Pattern Language: Towns Building Construction）中描述了一些常见的建筑设计问题，并提出了 253 种关于对城镇、邻里、住宅、花园和房间等进行设计的基本模式。

1979 年他的另一部经典著作《建筑的永恒之道》（The Timeless Way of Building）进一步强化了设计模式的思想，为后来的建筑设计指明了方向。

1987 年，肯特·贝克（Kent Beck）和沃德·坎宁安（Ward Cunningham）首先将克里斯托夫·亚历山大的模式思想应用在 Smalltalk 中的图形用户接口的生成中，但没有引起软件界的关注。

直到 1990 年，软件工程界才开始研讨设计模式的话题，后来召开了多次关于设计模式的研讨会。

1995 年，艾瑞克·伽马（ErichGamma）、理査德·海尔姆（Richard Helm）、拉尔夫·约翰森（Ralph Johnson）、约翰·威利斯迪斯（John Vlissides）等 4 位作者合作出版了《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）一书，在本教程中收录了 23 个设计模式，这是设计模式领域里程碑的事件，导致了软件设计模式的突破。这 4 位作者在软件开发领域里也以他们的“四人组”（Gang of Four，GoF）匿名著称。

直到今天，狭义的设计模式还是本教程中所介绍的 23 种经典设计模式。

软件设计模式的概念与意义

有关软件设计模式的定义很多，有些从模式的特点来说明，有些从模式的作用来说明。本教程给出的定义是大多数学者公认的，从以下两个方面来说明。

1. 软件设计模式的概念
   软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
2. 学习设计模式的意义
   设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点：

• 可以提高程序员的思维能力、编程能力和设计能力。
• 使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
• 使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。

当然，软件设计模式只是一个引导。在具体的软件幵发中，必须根据设计的应用系统的特点和要求来恰当选择。对于简单的程序开发，苛能写一个简单的算法要比引入某种设计模式更加容易。但对大项目的开发或者框架设计，用设计模式来组织代码显然更好。

软件设计模式的基本要素

软件设计模式使人们可以更加简单方便地复用成功的设计和体系结构，它通常包含以下几个基本要素：模式名称、别名、动机、问题、解决方案、效果、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式等，其中最关键的元素包括以下 4 个主要部分。

1. 模式名称
   每一个模式都有自己的名字，通常用一两个词来描述，可以根据模式的问题、特点、解决方案、功能和效果来命名。模式名称（PatternName）有助于我们理解和记忆该模式，也方便我们来讨论自己的设计。
2. 问题
   问题（Problem）描述了该模式的应用环境，即何时使用该模式。它解释了设计问题和问题存在的前因后果，以及必须满足的一系列先决条件。
3. 解决方案
   模式问题的解决方案（Solution）包括设计的组成成分、它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象的 组合）来解决这个问题。
4. 效果
   描述了模式的应用效果以及使用该模式应该权衡的问题，即模式的优缺点。主要是对时间和空间的衡量，以及该模式对系统的灵活性、扩充性、可移植性的影响，也考虑其实现问题。显式地列出这些效果（Consequence）对理解和评价这些模式有很大的帮助。

23 种设计模式的分类和功能

设计模式有两种分类方法，即根据模式的目的来分和根据模式的作用的范围来分。

1. 根据目的来分
   根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。
   创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。
   结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。
   行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。
2. 根据作用范围来分
   根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。
   类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。
   对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。GoF 中除了以上 4 种，其他的都是对象模式。

下表介绍了这 23 种设计模式的分类。

1. GoF的23种设计模式的功能

   前面说明了 GoF 的 23 种设计模式的分类，现在对各个模式的功能进行介绍。

   1. 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
   2. 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
   3. 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
   4. 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
   5. 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
   6. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
   7. 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
   8. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
   9. 装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
   10. 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
   11. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
   12. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
   13. 模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
   14. 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
   15. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
   16. 责任链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
   17. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
   18. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
   19. 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
   20. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
   21. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
   22. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
   23. 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

必须指出，这 23 种设计模式不是孤立存在的，很多模式之间存在一定的关联关系，在大的系统开发中常常同时使用多种设计模式，所以必须重视。
虽然设计模式是个好东西，能够给我们带来各种好处，比如降低对象之间的耦合，增加程序的可复用性、可扩展性、可维护性等等。
但是我们也不应该滥用设计模式，设计模式在一定程序上会增加系统的复杂性。我们在写码时应该评估好各方面，避免过度设计。
另外，设计模式的各种角色也不是固定不变的，根据实际需要，我们可以适当的进行改动。

抽象工厂

抽象工厂模式提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

模式的结构与实现

抽象工厂模式同工厂方法模式一样，也是由抽象工厂、具体工厂、抽象产品和具体产品等 4 个要素构成，但抽象工厂中方法个数不同，抽象产品的个数也不同。现在我们来分析其基本结构和实现方法。
1.模式的结构

• 抽象工厂模式的主要角色如下：
  • 抽象工厂（Abstract Factory）：提供了创建产品的接口，它包含多个创建产品的方法 newProduct()，可以创建多个不同等级的产品。
  • 具体工厂（Concrete Factory）：主要是实现抽象工厂中的多个抽象方法，完成具体产品的创建。
  • 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能，抽象工厂模式有多个抽象产品。
  • 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它 同具体工厂之间是多对一的关系。

抽象工厂模式的结构图

2.模式的实现
从上图可以看出抽象工厂模式的结构同工厂方法模式的结构相似，不同的是其产品的种类不止一个，所以创建产品的方法也不止一个。下面给出抽象工厂和具体工厂的代码。

(1) 抽象工厂：提供了产品的生成方法。

复制代码

interface AbstractFactory
{
    public Product1 newProduct1();
    public Product2 newProduct2();
}

(2) 具体工厂：实现了产品的生成方法。

class ConcreteFactory1 implements AbstractFactory
{
    public Product1 newProduct1()
    {
        System.out.println("具体工厂 1 生成-->具体产品 11...");
        return new ConcreteProduct11();
    }
    public Product2 newProduct2()
    {
        System.out.println("具体工厂 1 生成-->具体产品 21...");
        return new ConcreteProduct21();
    }
}

模式的应用实例

现在，我们要建造一个工厂来生产原料，这个工厂将负责创建原料家族中的每一种原料。也就是说，工厂将需要生产面团、酱料、芝士等。

开始先为工厂定义一个接口，这个接口负责创建所有的原料：

复制代码

public interface PizzaIngredientFactory {
    // 在接口中，每个原料都有一个对应的方法创建该原料
    public Dough createDough();
    public Sauce createSauce();
    public Cheese createCheese();
    public Veggies[] createVeggies();
    public Pepperoni createPepperoni();
    public Clams createClams();

}

现在要做的事情是：

1. 为每个区域建造一个工厂。你需要创建一个继承自PizzaIngredientFactory的子类来实现每一个创建方法；
2. 实现一组原料类供工厂使用，例如ReggianoCheese、RedPeppers、ThickCrustDough。这些类可以在合适的区域间共享；
3. 然后你需要将一切组织起来，将新的原料工厂整合进旧的PizzaStore代码中。

创建原料工厂

这是原料工厂的实现。这工厂专精于大蒜番茄酱料、Reggiano干酪、新鲜蛤蜊。

public class NYPizzaIngredientFactory implements PizzaIngredientFactory {
    // 对于原料家族内的每一种原料，我们都提供了纽约的版本
    @Override
    public Dough createDough() {
        return new ThinCrushDough();
    } 

    @Override
    public Sauce createSauce() {
        return new MarinaraSauce();
    } 

    @Override
    public Cheese createCheese() {
        return new ReggianoCheese();
    }
 
    @Override
    public Veggies[] createVeggies() {
        Veggies veggies[] = {new Garlic(), new Onion(), new Mushroom(), new RedPepper()};
        return veggies;
    } 

    @Override
    public Pepperoni createPepperoni() {
        // 这是切片的意式腊肠，纽约和芝加哥都会用到它
        return new SlicedPepperoni();
    }
 
    @Override
    public Clams createClams() {
        // 靠海，所以有新鲜的蛤蜊。芝加哥就必须使用冷冻的蛤蜊
        return new FreshClams();
    }
}

重做披萨

工厂已经一切就绪，准备生成高质量原料了。现在我们只需要重做披萨，好让它们只使用工厂生产出来的原料。我们先从抽象的Pizza类开始：

复制代码

public abstract class Pizza {

    String name;
    // 每个披萨都持有一组在准备时会用到的原料
    Dough dough;
    Sauce sauce;
    Veggies veggies[];
    Cheese cheese;
    Pepperoni pepperoni;
    Clams clams;

    // 现在把prepare()方法声明成抽象。在这个方法中，我们需要收集披萨所需的原料，而这些原料当然是来自原料工厂了。
   abstract void prepare();
    // 其他的方法保持不动
    void bake(){
        // ...
    }
    void cut(){
        // ...
    }
    void box(){
        // ...
    }
}

现在已经有了一个抽象披萨，可以开始创建纽约和芝加哥风味的披萨了。从今以后，加盟店必须直接从工厂取得原料。

我们曾经写过工厂方法的代码，有NYCheesePizza和ChicagoCheesePizza类。比较一下这两个类，唯一的差别在于使用区域性的原料，至于披萨的做法都一样。它们都依循着相同的准备步骤，只是使用不同的原料。

所以，其实我们不需要设计两个不同的类来处理不同风味的披萨，让原料工厂处理这种区域差异就可以了。下面是CheesePizza：

public class CheesePizza extends Pizza {

    PizzaIngredientFactory ingredientFactory;
    // 要制作披萨，需要工厂提供原料。
    // 所以每个披萨类都需要从构造器参数中得到一个工厂，并把这个工厂存储在一个实例变量中。
    public CheesePizza(PizzaIngredientFactory ingredientFactory){
        this.ingredientFactory = ingredientFactory;
    }

    @Override
    void prepare() {

        // prepare()方法一步一步地创建芝士披萨，每当需要原料时，就跟工厂要。
        dough = ingredientFactory.createDough();
        sauce = ingredientFactory.createSauce();
        cheese = ingredientFactory.createCheese();
    }
}

Pizza的代码利用相关的工厂生成原料。所生产的原料依赖所使用的工厂，Pizza类根本不关心这些原料，它只知道如何制作披萨。现在，Pizza和区域原料之间被解耦，无论原料工厂是在落基山脉还是在西北沿岸地区，Pizza类都可以轻易地复用，完全没有问题。

再回到披萨店

我们几乎完工了，只需再到加盟店短暂巡视一下，确认他们使用了正确的披萨。也需要让他们能和本地的原料工厂搭上线：

public class NYPizzaStore extends PizzaStore {
    protected Pizza createPizza(String item) {

        Pizza pizza = null;
        // 纽约店会用到纽约披萨原料工厂，由该原料工厂负责生产使用纽约风味披萨所需的原料
        PizzaIngredientFactory ingredientFactory = new NYPizzaIngredientFactory();
        if (item.equals("cheese")) {
            // 把工厂传递给每一个披萨，以便披萨能从工厂中取得原料
            pizza = new CheesePizza(ingredientFactory);
        } else if (item.equals("veggie")) {
            pizza = new VeggiePizza(ingredientFactory);
        } else if (item.equals("clam")) {
            pizza = new ClamPizza(ingredientFactory);
        } else if (item.equals("pepperoni")) {
            pizza = new PepperoniPizza(ingredientFactory);
        }
        return pizza;
    }
}

一连串的代码改变，我们到底做了些什么？

我们引入新类型的工厂，也就是所谓的抽象工厂，来创建披萨原料家族。

通过抽象工厂所提供的接口，可以创建产品的家族，利用这个接口书写代码，我们的代码将从实际工厂解耦，以便在不同环境中实现各式各样的工厂，制造出各种不同的产品。例如：不同的区域、不同的操作系统、不同的外观及操作。

因为代码从实际的产品中解耦了，所以我们可以替换不同的工厂来取得不同的行为，例如取得大蒜番茄酱料，而不是取得番茄酱料。

比较工厂方法和抽象工厂

PizzaStore实现为工厂方法，因为我们需要根据区域变化创建产品。通过工厂方法，每个区域都有自己的具体工厂，他们都知道如何制作适合该区域的披萨。

因为我们需要创建一个产品家族（也就是原料），我们把PizzaIngredientFactory实现为抽象工厂。每个子类都使用其区域的供货商来实现这些原料。

工厂方法使用继承，把对象的创建委托给子类，子类实现工厂方法来创建对象。工厂方法允许类将实例化延迟到子类进行。

抽象工厂使用对象组合，对象的创建被实现在工厂接口所暴露出来的方法中。抽象工厂创建相关的对象家族，而不需要依赖它们的具体类。

所有工厂都是用来封装对象的创建。所有工厂模式都通过减少应用程序和具体类之间