1、设计模式概述

1.1 介绍

本教程来自http://c.biancheng.net/view/1317.html
目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点：

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

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

1.2 分类

1.根据目的来分
根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。

创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。
GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。
结构型模式：用于描述如何将类或对象按某种布局组成更大的结构。
GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。
行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。
GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。

2.根据作用范围来分
根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。

类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。
GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。
对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。
GoF 中除了以上 4 种，其他的都是对象模式。

1.3 简要介绍23种设计模式的功能

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

2、UML

UML（Unified Modeling Language，统一建模语言）是用来设计软件蓝图的可视化建模语言，是一种为面向对象系统的产品进行说明、可视化和编制文档的标准语言，独立于任何一种具体的程序设计语言。

2.1 基本构件

在 UML 中，所有的描述由事物、关系和图这些构件组成。下图完整地描述了所有构件的关系：

2.1.1 事物

（1）结构事物

结构事物是模型中的静态部分，用以呈现概念或实体的表现元素，如下表所示。

（2）行为事物

行为事物指 UML 模型中的动态部分，如下表所示。

（3）分组事物

目前只有一种分组事物，即包。包纯碎是概念上的，只存在于开发阶段，结构事物、行为事物甚至分组事物都有可能放在一个包中，如下表所示。

（4）注释事物

注释事物是解释 UML 模型元素的部分，如下表所示。

2.1.2 图

在 UML 2.0 的 13 种图中，类图（Class Diagrams）是使用频率最高的 UML 图之一。类图描述系统中的类，以及各个类之间的关系的静态视图，能够让我们在正确编写代码之前对系统有一个全面的认识。类图是一种模型类型，确切地说，是一种静态模型类型。类图表示类、接口和它们之间的协作关系，用于系统设计阶段。

类、接口、类图

类图中，需注意以下几点：

抽象类或抽象方法用斜体表示
如果是接口，则在类名上方加 <>
字段和方法返回值的数据类型非必需
静态类或静态方法加下划线

2.1.3 关系

UML 将事物之间的联系归纳为 6 种，并用对应的图形类表示。下面根据类与类之间的耦合度从弱到强排列：
依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。

总结：

案例：

3、7种设计原则

3.1 开闭原则

定义

软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。

这里的软件实体包括以下几个部分：

项目中划分出的模块
类与接口
方法

开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

作用

开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。

对软件测试的影响
软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。
可以提高代码的可复用性
粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。
可以提高软件的可维护性
遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

实现

可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。

因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

下面以 Windows 的桌面主题为例介绍开闭原则的应用。
分析：Windows 的主题是桌面背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的桌面主题，也可以从网上下载新的主题。这些主题有共同的特点，可以为其定义一个抽象类（Abstract Subject），而每个具体的主题（Specific Subject）是其子类。用户窗体可以根据需要选择或者增加新的主题，而不需要修改原代码，所以它是满足开闭原则的，其类图如图 1 所示。

3.2 里氏替换

定义

继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects）。核心就是子类能完全替换它的基类。
里氏替换原则是继承与复用的基石，只有当子类可以替换掉基类，且系统的功能不受影响时，基类才能被复用，而子类也能够在基础类上增加新的行为。所以里氏替换原则指的是任何基类可以出现的地方，子类一定可以出现。
里氏替换原则是对 “开闭原则” 的补充，实现 “开闭原则” 的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏替换原则是对实现抽象化的具体步骤的规范。

作用

里氏替换原则的主要作用如下。

里氏替换原则是实现开闭原则的重要方式之一。
它克服了继承中重写父类造成的可复用性变差的缺点。
它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。
加强程序的健壮性，同时变更时可以做到非常好的兼容性，提高程序的维护性、可扩展性，降低需求变更时引入的风险。

实现

里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

根据上述理解，对里氏替换原则的定义可以总结如下：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
子类中可以增加自己特有的方法
当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松
当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等

（上面第3条的解释参见：https://blog.csdn.net/qq_39552268/article/details/112213037）

通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。

如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。

关于里氏替换原则的例子，最有名的是“正方形不是长方形”。当然，生活中也有很多类似的例子，例如，企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承“鸟”会飞的功能，所以它们不能定义成“鸟”的子类。同样，由于“气球鱼”不会游泳，所以不能定义成“鱼”的子类；“玩具炮”炸不了敌人，所以不能定义成“炮”的子类等。

下面以“几维鸟不是鸟”为例来说明里氏替换原则。

【例1】里氏替换原则在“几维鸟不是鸟”实例中的应用。

分析：鸟一般都会飞行，如燕子的飞行速度大概是每小时 120 千米。但是新西兰的几维鸟由于翅膀退化无法飞行。假如要设计一个实例，计算这两种鸟飞行 300 千米要花费的时间。显然，拿燕子来测试这段代码，结果正确，能计算出所需要的时间；但拿几维鸟来测试，结果会发生“除零异常”或是“无穷大”，明显不符合预期，其类图如图 1 所示。

public class LSPtest {public static void main(String[] args) {Bird bird1 = new Swallow();Bird bird2 = new BrownKiwi();bird1.setSpeed(120);bird2.setSpeed(120);System.out.println("如果飞行300公里：");try {System.out.println("燕子将飞行" + bird1.getFlyTime(300) + "小时.");System.out.println("几维鸟将飞行" + bird2.getFlyTime(300) + "小时。");} catch (Exception err) {System.out.println("发生错误了!");}}
}
//鸟类
class Bird {double flySpeed;public void setSpeed(double speed) {flySpeed = speed;}public double getFlyTime(double distance) {return (distance / flySpeed);}
}
//燕子类
class Swallow extends Bird {}
//几维鸟类
class BrownKiwi extends Bird {public void setSpeed(double speed) {flySpeed = 0;}
}

运行结果：

如果飞行300公里：
燕子将飞行2.5小时.
几维鸟将飞行Infinity小时。

程序运行错误的原因是：几维鸟类重写了鸟类的 setSpeed(double speed) 方法，这违背了里氏替换原则。正确的做法是：取消几维鸟原来的继承关系，定义鸟和几维鸟的更一般的父类，如动物类，它们都有奔跑的能力。几维鸟的飞行速度虽然为 0，但奔跑速度不为 0，可以计算出其奔跑 300 千米所要花费的时间。其类图如图 2 所示。

3.3 依赖倒置

定义

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。

由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。

使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。

作用

依赖倒置原则的主要作用如下。

依赖倒置原则可以降低类间的耦合性。
依赖倒置原则可以提高系统的稳定性。
依赖倒置原则可以减少并行开发引起的风险。
依赖倒置原则可以提高代码的可读性和可维护性。

实现

依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。

每个类尽量提供接口或抽象类，或者两者都具备。
变量的声明类型尽量是接口或者是抽象类。
任何类都不应该从具体类派生。
使用继承时尽量遵循里氏替换原则。

下面以“顾客购物程序”为例来说明依赖倒置原则的应用。

【例1】依赖倒置原则在“顾客购物程序”中的应用。

分析：本程序反映了 “顾客类”与“商店类”的关系。商店类中有 sell() 方法，顾客类通过该方法购物以下代码定义了顾客类通过韶关网店 ShaoguanShop 购物：

class Customer {public void shopping(ShaoguanShop shop) {//购物System.out.println(shop.sell());}
}

但是，这种设计存在缺点，如果该顾客想从另外一家商店（如婺源网店 WuyuanShop）购物，就要将该顾客的代码修改如下：

class Customer {public void shopping(WuyuanShop shop) {//购物System.out.println(shop.sell());}
}

顾客每更换一家商店，都要修改一次代码，这明显违背了开闭原则。存在以上缺点的原因是：顾客类设计时同具体的商店类绑定了，这违背了依赖倒置原则。解决方法是：定义“婺源网店”和“韶关网店”的共同接口 Shop，顾客类面向该接口编程，其代码修改如下：

class Customer {public void shopping(Shop shop) {//购物System.out.println(shop.sell());}
}

这样，不管顾客类 Customer 访问什么商店，或者增加新的商店，都不需要修改原有代码了，其类图如图 1 所示。

public class DIPtest {public static void main(String[] args) {Customer wang = new Customer();System.out.println("顾客购买以下商品：");wang.shopping(new ShaoguanShop());wang.shopping(new WuyuanShop());}
}
//商店
interface Shop {public String sell(); //卖
}
//韶关网店
class ShaoguanShop implements Shop {public String sell() {return "韶关土特产：香菇、木耳……";}
}
//婺源网店
class WuyuanShop implements Shop {public String sell() {return "婺源土特产：绿茶、酒糟鱼……";}
}
//顾客
class Customer {public void shopping(Shop shop) {//购物System.out.println(shop.sell());}
}

程序的运行结果如下：

顾客购买以下商品：
韶关土特产：香菇、木耳……
婺源土特产：绿茶、酒糟鱼……

3.4 单一职责

定义

又称单一功能原则。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

作用

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
提高类的可读性。复杂性降低，自然其可读性会提高。
提高系统的可维护性。可读性提高，那自然更容易维护了。
变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

实现

单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。
下面以大学学生工作管理程序为例介绍单一职责原则的应用。
分析：大学学生工作主要包括学生生活辅导和学生学业指导两个方面的工作，其中生活辅导主要包括班委建设、出勤统计、心理辅导、费用催缴、班级管理等工作，学业指导主要包括专业引导、学习辅导、科研指导、学习总结等工作。如果将这些工作交给一位老师负责显然不合理，正确的做法是生活辅导由辅导员负责，学业指导由学业导师负责，其类图如图所示。

注意：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

3.5 接口隔离

定义

要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。客户端不应该被迫依赖于它不使用的方法。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上。
以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

作用

接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。

将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

实现

在具体应用接口隔离原则时，应该根据以下几个规则来衡量。

接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

下面以学生成绩管理程序为例介绍接口隔离原则的应用。
分析：学生成绩管理程序一般包含插入成绩、删除成绩、修改成绩、计算总分、计算均分、打印成绩信息、査询成绩信息等功能，如果将这些功能全部放到一个接口中显然不太合理，正确的做法是将它们分别放在输入模块、统计模块和打印模块等 3 个模块中，其类图如图 1 所示。

public class ISPtest {public static void main(String[] args) {InputModule input = StuScoreList.getInputModule();CountModule count = StuScoreList.getCountModule();PrintModule print = StuScoreList.getPrintModule();input.insert();count.countTotalScore();print.printStuInfo();//print.delete();}
}
//输入模块接口
interface InputModule {void insert();void delete();void modify();
}
//统计模块接口
interface CountModule {void countTotalScore();void countAverage();
}
//打印模块接口
interface PrintModule {void printStuInfo();void queryStuInfo();
}
//实现类
class StuScoreList implements InputModule, CountModule, PrintModule {private StuScoreList() {}public static InputModule getInputModule() {return (InputModule) new StuScoreList();}public static CountModule getCountModule() {return (CountModule) new StuScoreList();}public static PrintModule getPrintModule() {return (PrintModule) new StuScoreList();}public void insert() {System.out.println("输入模块的insert()方法被调用！");}public void delete() {System.out.println("输入模块的delete()方法被调用！");}public void modify() {System.out.println("输入模块的modify()方法被调用！");}public void countTotalScore() {System.out.println("统计模块的countTotalScore()方法被调用！");}public void countAverage() {System.out.println("统计模块的countAverage()方法被调用！");}public void printStuInfo() {System.out.println("打印模块的printStuInfo()方法被调用！");}public void queryStuInfo() {System.out.println("打印模块的queryStuInfo()方法被调用！");}
}

运行结果：

输入模块的insert()方法被调用！
统计模块的countTotalScore()方法被调用！
打印模块的printStuInfo()方法被调用！

3.6 迪米特

定义

又叫作最少知识原则。迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

作用

迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。

降低了类之间的耦合度，提高了模块的相对独立性。
由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

实现

从迪米特法则的定义和特点可知，它强调以下两点：

从依赖者的角度来说，只依赖应该依赖的对象。
从被依赖者的角度说，只暴露应该暴露的方法。

所以，在运用迪米特法则时要注意以下 6 点。

在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
在类的结构设计上，尽量降低类成员的访问权限。
在类的设计上，优先考虑将一个类设置成不变类。
在对其他类的引用上，将引用其他对象的次数降到最低。
不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
谨慎使用序列化（Serializable）功能。

【例1】明星与经纪人的关系实例。
分析：明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则，其类图如图 1 所示。

public class LoDtest {public static void main(String[] args) {Agent agent = new Agent();agent.setStar(new Star("林心如"));agent.setFans(new Fans("粉丝韩丞"));agent.setCompany(new Company("中国传媒有限公司"));agent.meeting();agent.business();}
}
//经纪人
class Agent {private Star myStar;private Fans myFans;private Company myCompany;public void setStar(Star myStar) {this.myStar = myStar;}public void setFans(Fans myFans) {this.myFans = myFans;}public void setCompany(Company myCompany) {this.myCompany = myCompany;}public void meeting() {System.out.println(myFans.getName() + "与明星" + myStar.getName() + "见面了。");}public void business() {System.out.println(myCompany.getName() + "与明星" + myStar.getName() + "洽淡业务。");}
}
//明星
class Star {private String name;Star(String name) {this.name = name;}public String getName() {return name;}
}
//粉丝
class Fans {private String name;Fans(String name) {this.name = name;}public String getName() {return name;}
}
//媒体公司
class Company {private String name;Company(String name) {this.name = name;}public String getName() {return name;}
}

运行结果：

粉丝韩丞与明星林心如见面了。
中国传媒有限公司与明星林心如洽淡业务。

3.7 合成复用

定义

又叫组合/聚合复用原则，它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

作用

通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。

继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。

它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

实现

合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

下面以汽车分类管理程序为例来介绍合成复用原则的应用。

分析：汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。图 1 所示是用继承关系实现的汽车分类的类图。

从上图可以看出用继承关系实现会产生很多子类，而且增加新的“动力源”或者增加新的“颜色”都要修改源代码，这违背了开闭原则，显然不可取。但如果改用组合关系实现就能很好地解决以上问题，其类图如下图所示。

3.8 总结

各种原则要求的侧重点不同，下面我们分别用一句话归纳总结软件设计模式的七大原则，如下表所示。

实际上，这些原则的目的只有一个：降低对象之间的耦合，增加程序的可复用性、可扩展性和可维护性。

记忆口诀：访问加限制，函数要节俭，依赖不允许，动态加接口，父类要抽象，扩展不更改。

在程序设计时，我们应该将程序功能最小化，每个类只干一件事。若有类似功能基础之上添加新功能，则要合理使用继承。对于多方法的调用，要会运用接口，同时合理设置接口功能与数量。最后类与类之间做到低耦合高内聚。

4、23中设计模式介绍

开始学习设计模式前，我们先来看看软件架构的设计过程，及需要达成的目标和尽量避免的陷阱。

代码复用

无论是开发哪种软件产品，成本和时间都是最重要的。较少的开发时间意味着可以比竞争对手更早进入市场。较低的开发成本意味着能够留出更多的营销资金，覆盖更广泛的潜在客户。

其中，代码复用是减少开发成本最常用的方式之一，其目的非常明显，即：与其反复从头开发，不如在新对象中重用已有的代码。

这个想法表面看起来很棒，但实际上要让已有的代码在全新的代码中工作，还是需要付出额外努力的。组件间紧密的耦合、对具体类而非接口的依赖和硬编码的行为都会降低代码的灵活性，使得复用这些代码变得更加困难。

使用设计模式是增加软件组件灵活性并使其易于复用的方式之一。但是，这可能也会让组件变得更加复杂。

一般情况下，复用可以分为三个层次。在最底层，可以复用类、类库、容器，也许还有一些类的“团体（例如容器和迭代器）”。

框架位于最高层。它们能帮助你精简自己的设计，可以明确解决问题所需的抽象概念，然后用类来表示这些概念并定义其关系。例如，JUnit 是一个小型框架，也是框架的“Hello, world”，其中定义了 Test、TestCase 和 TestSuite 这几个类及其关系。框架通常比单个类的颗粒度要大。你可以通过在某处构建子类来与框架建立联系。这些子类信奉“别给我们打电话，我们会给你打电话的。”

还有一个中间层次。这是我觉得设计模式所处的位置。设计模式比框架更小且更抽象。它们实际上是对一组类的关系及其互动方式的描述。当你从类转向模式，并最终到达框架的过程中，复用程度会不断增加。

中间层次的优点在于模式提供的复用方式要比框架的风险小。创建框架是一项投入重大且风险很高的工作，模式则能让你独立于具体代码来复用设计思想和理念。

扩展性

需求变化是程序员生命中唯一不变的事情。比如以下几种场景：

你在 Windows 平台上发布了一款游戏，现在人们想要 Mac OS 的版本。
你创建了一个使用方形按钮的 GUI 框架，但几个月后开始流行原型按钮。
你设计了一款优秀的电子商务网站，但仅仅几个月后，客户就要求新增电话订单的功能。

每个软件开发者都经历过许多相似的故事，导致它们发生的原因也不少。

首先，在完成了第一版的程序后，我们就应该做好了从头开始优化重写代码的准备，因为现在你已经能在很多方面更好的理解问题了，同时在专业水平上也有所提高，所以之前的代码现在看上去可能会显得很糟糕。

其次，可能是在你掌控之外的某些事情发生了变化，这也是导致许多开发团队转变最初想法的原因。比如，每位在网络应用中使用 Flash 的开发者都必须重新开发或移植代码，因为不断地有浏览器停止对 Flash 格式地支持。

最后，可能是需求的改变，之前你的客户对当前版本的程序感到满意，但是现在希望对程序进行 11 个“小小”的改动，使其可完成原始计划阶段中完全没有提到的功能，新增或改变功能。

当然这也有好的一面，如果有人要求你对程序进行修改，至少说明还有人关心它。因此在设计程序架构时，有经验的开发者都会尽量选择支持未来任何可能变更的方式。

如何正确使用设计模式？

设计模式不是为每个人准备的，而是基于业务来选择设计模式，需要时就能想到它。要明白一点，技术永远为业务服务，技术只是满足业务需要的一个工具。我们需要掌握每种设计模式的应用场景、特征、优缺点，以及每种设计模式的关联关系，这样就能够很好地满足日常业务的需要。

许多设计模式的功能类似，界限不是特别清楚（为了能让大家更好的理解，每个章节后面都列出了类似功能设计模式之间的对比）。大家不要疑惑，设计模式不是为了特定场景而生的，而是为了让大家可以更好和更快地开发。

设计模式只是实现了七大设计原则的具体方式，套用太多设计模式只会陷入模式套路陷阱，最后代码写的凌乱不堪。

在实际工作中很少会规定必须使用哪种设计模式，这样只会限制别人。不能为了使用设计模式而去做架构，而是有了做架构的需求后，发现它符合某一类设计模式的结构，在将两者结合。

设计模式要活学活用，不要生搬硬套。想要游刃有余地使用设计模式，需要打下牢固的程序设计语言基础、夯实自己的编程思想、积累大量的时间经验、提高开发能力。目的都是让程序低耦合，高复用，高内聚，易扩展，易维护。

需求驱动
不仅仅是功能性需求，需求驱动还包括性能和运行时的需求，如软件的可维护性和可复用性等方面。设计模式是针对软件设计的，而软件设计是针对需求的，一定不要为了使用设计模式而使用设计模式，否则可能会使设计变得复杂，使软件难以调试和维护。
分析成功的模式应用项目
对现有的应用实例进行分析是一个很好的学习途径，应当注意学习已有的项目，而不仅是学习设计模式如何实现，更重要的是注意在什么场合使用设计模式。
充分了解所使用的开发平台
设计模式大部分都是针对面向对象的软件设计，因此在理论上适合任何面向对象的语言，但随着技术的发展和编程环境的改善，设计模式的实现方式会有很大的差别。在一些平台下，某些设计模式是自然实现的。

不仅指编程语言，平台还包括平台引入的技术。例如，Java EE 引入了反射机制和依赖注入，这些技术的使用使设计模式的实现方式产生了改变。
4. 在编程中领悟模式
软件开发是一项实践工作，最直接的方法就是编程。没有从来不下棋却熟悉定式的围棋高手，也没有不会编程就能成为架构设计师的先例。掌握设计模式是水到渠成的事情，除了理论只是和实践积累，可能会“渐悟”或者“顿悟”。
5.避免设计过度
设计模式解决的是设计不足的问题，但同时也要避免设计过度。一定要牢记简洁原则，要知道设计模式是为了使设计简单，而不是更复杂。如果引入设计模式使得设计变得复杂，只能说我们把简单问题复杂化了，问题本身不需要设计模式。

这里需要把握的是需求变化的程度，一定要区分需求的稳定部分和可变部分。一个软件必然有稳定部分，这个部分就是核心业务逻辑。如果核心业务逻辑发生变化，软件就没有存在的必要，核心业务逻辑是我们需要固化的。对于可变的部分，需要判断可能发生变化的程度来确定设计策略和设计风险。要知道，设计过度与设计不足同样对项目有害。
学习设计模式，死记硬背是没用的，还要从实践中理解，本教程后面会结合实例和源码来讲解如何使用设计模式。

需要特别声明的是，在日常应用中，设计模式从来都不是单个设计模式独立使用的。在实际应用中，通常多个设计模式混合使用，你中有我，我中有你。下图完整地描述了设计模式之间的混用关系，希望对大家有所帮助。

创建型模式

创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。就像我们去商场购买商品时，不需要知道商品是怎么生产出来一样，因为它们由专门的厂商生产。

创建型模式分为以下几种。

单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

4.1 单例模式

定义特点

指一个类只有一个实例，且该类能自行创建这个实例的一种模式。

单例模式有 3 个特点：

单例类只有一个实例对象；
该单例对象必须由单例类自行创建；
单例类对外提供一个访问该单例的全局访问点。

优缺点

单例模式的优点：

单例模式可以保证内存里只有一个实例，减少了内存的开销。
可以避免对资源的多重占用。
单例模式设置全局访问点，可以优化和共享资源的访问。

单例模式的缺点：

单例模式一般没有接口，扩展困难。如果要扩展，则除了修改原来的代码，没有第二种途径，违背开闭原则。
在并发测试中，单例模式不利于代码调试。在调试过程中，如果单例中的代码没有执行完，也不能模拟生成一个新的对象。
单例模式的功能代码通常写在一个类中，如果功能设计不合理，则很容易违背单一职责原则。

使用场景

例如，Windows 中只能打开一个任务管理器，这样可以避免因打开多个任务管理器窗口而造成内存资源的浪费，或出现各个窗口显示内容的不一致等错误。

在计算机系统中，还有 Windows 的回收站、操作系统中的文件系统、多线程中的线程池、显卡的驱动程序对象、打印机的后台处理服务、应用程序的日志对象、数据库的连接池、网站的计数器、Web 应用的配置对象、应用程序中的对话框、系统中的缓存等常常被设计成单例。

单例模式在现实生活中的应用也非常广泛，例如公司 CEO、部门经理等都属于单例模型。J2EE 标准中的 ServletContext 和 ServletContextConfig、Spring 框架应用中的 ApplicationContext、数据库中的连接池等也都是单例模式。

对于 Java 来说，单例模式可以保证在一个 JVM 中只存在单一实例。单例模式的应用场景主要有以下几个方面。

需要频繁创建的一些类，使用单例可以降低系统的内存压力，减少 GC。
某类只要求生成一个对象的时候，如一个班中的班长、每个人的身份证号等。
某些类创建实例时占用资源较多，或实例化耗时较长，且经常使用。
某类需要频繁实例化，而创建的对象又频繁被销毁的时候，如多线程的线程池、网络连接池等。
频繁访问数据库或文件的对象。
对于一些控制硬件级别的操作，或者从系统上来讲应当是单一控制逻辑的操作，如果有多个实例，则系统会完全乱套。
当对象需要被共享的场合。由于单例模式只允许创建一个对象，共享该对象可以节省内存，并加快对象访问速度。如 Web 中的配置对象、数据库的连接池等。

实现

单例模式是设计模式中最简单的模式之一。通常，普通类的构造函数是公有的，外部类可以通过“new 构造函数()”来生成多个实例。但是，如果将类的构造函数设为私有的，外部类就无法调用该构造函数，也就无法生成多个实例。这时该类自身必须定义一个静态私有实例，并向外提供一个静态的公有函数用于创建或获取该静态私有实例。

第 1 种：懒汉式单例(双重检查保证效率)

该模式的特点是类加载时没有生成单例，只有当第一次调用 getlnstance 方法时才去创建这个单例。

class Singleton {private Singleton() {}private static volatile Singleton instance;public static Singleton getInstance() {if (instance==null){synchronized (Singleton.class) {if (instance == null) {instance = new Singleton();}}}return instance;}
}

如果编写的是多线程程序，则不要删除上例代码中的关键字 volatile 和 synchronized，否则将存在线程非安全的问题。

第 2 种：饿汉式单例

该模式的特点是类一旦加载就创建一个单例，保证在调用 getInstance 方法之前单例已经存在了。

public class HungrySingleton {private static final HungrySingleton instance = new HungrySingleton();private HungrySingleton() {}public static HungrySingleton getInstance() {return instance;}
}

饿汉式单例在类创建的同时就已经创建好一个静态的对象供系统使用，以后不再改变，所以是线程安全的，可以直接用于多线程而不会出现问题。

单例模式的扩展

单例模式可扩展为有限的多例（Multitcm）模式，这种模式可生成有限个实例并保存在 ArrayList 中，客户需要时可随机获取。

4.2 原型模式

定义特点

原型（Prototype）模式的定义如下：用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型相同或相似的新对象。在这里，原型实例指定了要创建的对象的种类。用这种方式创建对象非常高效，根本无须知道对象创建的细节。

优缺点

原型模式的优点：

Java 自带的原型模式基于内存二进制流的复制，在性能上比直接 new 一个对象更加优良。
可以使用深克隆方式保存对象的状态，使用原型模式将对象复制一份，并将其状态保存起来，简化了创建对象的过程，以便在需要的时候使用（例如恢复到历史某一状态），可辅助实现撤销操作。

原型模式的缺点：

需要为每一个类都配置一个 clone 方法
clone 方法位于类的内部，当对已有类进行改造的时候，需要修改代码，违背了开闭原则。
当实现深克隆时，需要编写较为复杂的代码，而且当对象之间存在多重嵌套引用时，为了实现深克隆，每一层对象对应的类都必须支持深克隆，实现起来会比较麻烦。因此，深克隆、浅克隆需要运用得当。

使用场景

例如，Windows 操作系统的安装通常较耗时，如果复制就快了很多。在生活中复制的例子非常多，这里不一一列举了。

原型模式通常适用于以下场景。

对象之间相同或相似，即只是个别的几个属性不同的时候。
创建对象成本较大，例如初始化时间长，占用CPU太多，或者占用网络资源太多等，需要优化资源。
创建一个对象需要繁琐的数据准备或访问权限等，需要提高性能或者提高安全性。
系统中大量使用该类对象，且各个调用者都需要给它的属性重新赋值。

在 Spring 中，原型模式应用的非常广泛，例如 scope=‘prototype’、JSON.parseObject() 等都是原型模式的具体应用。

实现

原型模式的克隆分为浅克隆和深克隆。

浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型属性，仍指向原有属性所指向的对象的内存地址。
深克隆：创建一个新对象，属性中引用的其他对象也会被克隆，不再指向原有对象地址。

注：String类型通过常量赋值时相当于基本数据类型，通过new关键字创建对象时便是引用数据类型。

String str1 = new String("ABC");
String str2 = new String("ABC");
System.out.println(str1 == str2); //falseString str3 = "ABC";
String str4 = "ABC";
String str5 =  "AB" + "C";
System.out.println(str3 == str4);   //true
System.out.println(str3 == str5);  // trueString a  = "ABC";
String b = "AB";
String c = b + "C";
System.out.println( a == c );//false

注意最后一个a与c相等的判断:a、b在编译时就已经被确定了，而c是引用变量，不会在编译时就被确定。运行时b与“C”的拼接是通过StringBuilder（JDK1.5之前是StringBuffer）实现的，最后调用的StringBuilder的toString函数返回一个新的String对象。

浅克隆

Java 中的 Object 类提供了浅克隆的 clone() 方法，具体原型类只要实现 Cloneable 接口就可实现对象的浅克隆，这里的 Cloneable 接口就是抽象原型类。其代码如下：

//具体原型类
class Realizetype implements Cloneable {public String name="coder";Realizetype() {System.out.println("具体原型创建成功！");}public Object clone() throws CloneNotSupportedException {System.out.println("具体原型复制成功！");return super.clone();}
}
//原型模式的测试类
public class PrototypeTest {public static void main(String[] args) throws CloneNotSupportedException {Realizetype obj1 = new Realizetype();Realizetype obj2 = (Realizetype) obj1.clone();System.out.println("obj1==obj2?" + (obj1 == obj2));System.out.println("clone1.name==realizetype1.name?"+(clone1.name==realizetype1.name));}
}

运行结果：

具体原型创建成功！
具体原型复制成功！
obj1==obj2?false

深克隆

两种实现方式：重写clone、通过对象序列化

方法一：重写clone

与通过重写clone方法实现浅拷贝的基本思路一样，只需要为对象图的每一层的每一个对象都实现Cloneable接口并重写clone方法，最后在最顶层的类的重写的clone方法中调用所有的clone方法即可实现深拷贝。简单的说就是：每一层的每个对象都进行浅拷贝=深拷贝。

public class DeepCopy {public static void main(String[] args) {Student s1 = new Student("s1", new Age(20), 175);Student clone = (Student) s1.clone();System.out.println(clone.getAge()==s1.getAge());System.out.println();}
}class Age implements Cloneable {private int age;public int getAge() {return age;}public void setAge(int age) {this.age = age;}public Age(int age) {this.age = age;}@Overridepublic String toString() {return "Age{" +"age=" + age +'}';}@Overrideprotected Object clone() {Object object = null;try {object = super.clone();} catch (CloneNotSupportedException e) {e.printStackTrace();}return object;}
}class Student implements Cloneable {private String name;private Age age;private int length;public String getName() {return name;}public void setName(String name) {this.name = name;}public Age getAge() {return age;}public void setAge(Age age) {this.age = age;}public int getLength() {return length;}public void setLength(int length) {this.length = length;}@Overridepublic String toString() {return "Student{" +"name='" + name + '\'' +", age=" + age +", length=" + length +'}';}public Student(String name, Age age, int length) {this.name = name;this.age = age;this.length = length;}@Overrideprotected Object clone() {Object object = null;try {object = super.clone();} catch (CloneNotSupportedException e) {e.printStackTrace();}Student student = (Student) object;student.age = (Age) student.getAge().clone();return object;}
}

方法二：通过对象序列化

虽然层次调用clone方法可以实现深拷贝，但是显然代码量实在太大。特别对于属性数量比较多、层次比较深的类而言，每个类都要重写clone方法太过繁琐。

将对象序列化为字节序列后，默认会将该对象的整个对象图进行序列化，再通过反序列即可完美地实现深拷贝。

import java.io.*;public class DeepCopy {public static void main(String[] args) throws IOException, ClassNotFoundException {Age age = new Age(20);Student s1 = new Student("s1", age, 180);ByteArrayOutputStream bos = new ByteArrayOutputStream();ObjectOutputStream oos = new ObjectOutputStream(bos);oos.writeObject(s1);oos.flush();ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());ObjectInputStream ois = new ObjectInputStream(bis);Student clone = (Student) ois.readObject();ois.close();bis.close();oos.close();bos.close();System.out.println(clone == s1);System.out.println();}
}class Age implements Serializable {private int age;public int getAge() {return age;}public void setAge(int age) {this.age = age;}public Age(int age) {this.age = age;}@Overridepublic String toString() {return "Age{" +"age=" + age +'}';}}class Student implements Serializable {private String name;private Age age;private int length;public String getName() {return name;}public void setName(String name) {this.name = name;}public Age getAge() {return age;}public void setAge(Age age) {this.age = age;}public int getLength() {return length;}public void setLength(int length) {this.length = length;}@Overridepublic String toString() {return "Student{" +"name='" + name + '\'' +", age=" + age +", length=" + length +'}';}public Student(String name, Age age, int length) {this.name = name;this.age = age;this.length = length;}
}

原型模式的扩展

原型模式可扩展为带原型管理器的原型模式，它在原型模式的基础上增加了一个原型管理器 PrototypeManager 类。该类用 HashMap 保存多个复制的原型，Client 类可以通过管理器的 get(String id) 方法从中获取复制的原型。

工厂模式

在日常开发中，凡是需要生成复杂对象的地方，都可以尝试考虑使用工厂模式来代替。

注意：上述复杂对象指的是类的构造函数参数过多等对类的构造有影响的情况，因为类的构造过于复杂，如果直接在其他业务类内使用，则两者的耦合过重，后续业务更改，就需要在任何引用该类的源代码内进行更改，光是查找所有依赖就很消耗时间了，更别说要一个一个修改了。

工厂模式的定义：定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

按实际业务场景划分，工厂模式有 3 种不同的实现方式，分别是简单工厂模式、工厂方法模式和抽象工厂模式。

我们把被创建的对象称为“产品”，把创建产品的对象称为“工厂”。如果要创建的产品不多，只要一个工厂类就可以完成，这种模式叫“简单工厂模式”。

在简单工厂模式中创建实例的方法通常为静态（static）方法，因此简单工厂模式（Simple Factory Pattern）又叫作静态工厂方法模式（Static Factory Method Pattern）。

简单来说，简单工厂模式有一个具体的工厂类，可以生成多个不同的产品，属于创建型设计模式。

简单工厂模式每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度，违背了“开闭原则”。

“工厂方法模式”是对简单工厂模式的进一步抽象化，其好处是可以使系统在不修改原来代码的情况下引进新的产品，即满足开闭原则。

4.3 简单工厂模式

定义特点

优缺点

优点：
1- 工厂类包含必要的逻辑判断，可以决定在什么时候创建哪一个产品的实例。客户端可以免除直接创建产品对象的职责，很方便的创建出相应的产品。工厂和产品的职责区分明确。

客户端无需知道所创建具体产品的类名，只需知道参数即可。
也可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。

缺点：

简单工厂模式的工厂类单一，负责所有产品的创建，职责过重，一旦异常，整个系统将受影响。且工厂类代码会非常臃肿，违背高聚合原则。
使用简单工厂模式会增加系统中类的个数（引入新的工厂类），增加系统的复杂度和理解难度
系统扩展困难，一旦增加新产品不得不修改工厂逻辑，在产品类型较多时，可能造成逻辑过于复杂
简单工厂模式使用了 static 工厂方法，造成工厂角色无法形成基于继承的等级结构。

使用场景

对于产品种类相对较少的情况，考虑使用简单工厂模式。使用简单工厂模式的客户端只需要传入工厂类的参数，不需要关心如何创建对象的逻辑，可以很方便地创建所需产品。

实现

简单工厂模式的主要角色如下：

简单工厂（SimpleFactory）：是简单工厂模式的核心，负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。
抽象产品（Product）：是简单工厂创建的所有对象的父类，负责描述所有实例共有的公共接口。
具体产品（ConcreteProduct）：是简单工厂模式的创建目标。

其结构图如下图所示。

public class Client {public static void main(String[] args) {SimpleFactory sf = new SimpleFactory();Product productA = sf.makeProduct(0);Product productB = sf.makeProduct(1);productA.show();productB.show();}//抽象产品public interface Product {void show();}//具体产品：ProductAstatic class ConcreteProduct1 implements Product {public void show() {System.out.println("具体产品1显示...");}}//具体产品：ProductBstatic class ConcreteProduct2 implements Product {public void show() {System.out.println("具体产品2显示...");}}final class Const {static final int PRODUCT_A = 0;static final int PRODUCT_B = 1;static final int PRODUCT_C = 2;}static class SimpleFactory {public static Product makeProduct(int kind) {switch (kind) {case Const.PRODUCT_A:return new ConcreteProduct1();case Const.PRODUCT_B:return new ConcreteProduct2();}return null;}}
}

4.4 工厂方法模式

定义特点

在《简单工厂模式》一节我们介绍了简单工厂模式，提到了简单工厂模式违背了开闭原则，而“工厂方法模式”是对简单工厂模式的进一步抽象化，其好处是可以使系统在不修改原来代码的情况下引进新的产品，即满足开闭原则。

优缺点

优点：

用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程。
灵活性增强，对于新产品的创建，只需多写一个相应的工厂类。
典型的解耦框架。高层模块只需要知道产品的抽象类，无须关心其他实现类，满足迪米特法则、依赖倒置原则和里氏替换原则。

缺点：

类的个数容易过多，增加复杂度
增加了系统的抽象性和理解难度
抽象产品只能生产一种产品，此弊端可使用抽象工厂模式解决。

使用场景

客户只知道创建产品的工厂名，而不知道具体的产品名。如 TCL 电视工厂、海信电视工厂等。
创建对象的任务由多个具体子工厂中的某一个完成，而抽象工厂只提供创建产品的接口。
客户不关心创建产品的细节，只关心产品的品牌

实现

工厂方法模式由抽象工厂、具体工厂、抽象产品和具体产品等4个要素构成。
工厂方法模式的主要角色如下。

抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法 newProduct() 来创建产品。
具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。

其结构图如图 1 所示。

package com.atguigu;/*** @PackageName: com.atguigu* @ClassName: AbstractFactoryTest* @Author: user-lihao* @Date: 2021/10/12 20:40* @Description:**/
public class AbstractFactoryTest {public static Product getProduct(AbstractFactory af){Product p=af.newProduct();return p;}public static void main(String[] args) {Product product1 = getProduct(new ConcreteFactory1());product1.show();//具体产品1显示...}
}
//抽象产品：提供了产品的接口
interface Product {public void show();
}
//具体产品1：实现抽象产品中的抽象方法
class ConcreteProduct1 implements Product {public void show() {System.out.println("具体产品1显示...");}
}
//具体产品2：实现抽象产品中的抽象方法
class ConcreteProduct2 implements Product {public void show() {System.out.println("具体产品2显示...");}
}
//抽象工厂：提供了产品的生成方法
interface AbstractFactory {public Product newProduct();
}
//具体工厂1：实现了产品的生成方法
class ConcreteFactory1 implements AbstractFactory {public Product newProduct() {System.out.println("具体工厂1生成-->具体产品1...");return new ConcreteProduct1();}
}
//具体工厂2：实现了产品的生成方法
class ConcreteFactory2 implements AbstractFactory {public Product newProduct() {System.out.println("具体工厂2生成-->具体产品2...");return new ConcreteProduct2();}
}

4.5 抽象工厂模式

同种类称为同等级，也就是说：工厂方法模式只考虑生产同等级的产品，但是在现实生活中许多工厂是综合型的工厂，能生产多等级（种类）的产品，如农场里既养动物又种植物，电器厂既生产电视机又生产洗衣机或空调，大学既有软件专业又有生物专业等。

本节要介绍的抽象工厂模式将考虑多等级产品的生产，将同一个具体工厂所生产的位于不同等级的一组产品称为一个产品族，下图所示的是海尔工厂和 TCL 工厂所生产的电视机与空调对应的关系图。

定义特点

抽象工厂（AbstractFactory）模式的定义：是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。

抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。

优缺点

抽象工厂模式除了具有工厂方法模式的优点外，其他主要优点如下。

可以在类的内部对产品族中相关联的多等级产品共同管理，而不必专门引入多个新的类来进行管理。
当需要产品族时，抽象工厂可以保证客户端始终只使用同一个产品的产品组。
抽象工厂增强了程序的可扩展性，当增加一个新的产品族时，不需要修改原代码，满足开闭原则。

其缺点是：当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。增加了系统的抽象性和理解难度。

使用场景

使用抽象工厂模式一般要满足以下条件：

系统中有多个产品族，每个具体工厂创建同一族但属于不同等级结构的产品。
系统一次只可能消费其中某一族产品，即同族的产品一起使用。

抽象工厂模式最早的应用是用于创建属于不同操作系统的视窗构件。如 Java 的 AWT 中的 Button 和 Text 等构件在 Windows 和 UNIX 中的本地实现是不同的。

抽象工厂模式通常适用于以下场景：

当需要创建的对象是一系列相互关联或相互依赖的产品族时，如电器工厂中的电视机、洗衣机、空调等。
系统中有多个产品族，但每次只使用其中的某一族产品。如有人只喜欢穿某一个品牌的衣服和鞋。
系统中提供了产品的类库，且所有产品的接口相同，客户端不依赖产品实例的创建细节和内部结构。

实现

抽象工厂模式的主要角色如下。

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

抽象工厂结构如下:

public class AbstractFactoryTest {public static Product1 getProduct1(AbstractFactory af) {return af.newProduct1();}public static Product2 getProduct2(AbstractFactory af) {return af.newProduct2();}public static void main(String[] args) {Product1 p2 = getProduct1(new ConcreteFactory2());p2.show();//product21-show()Product2 p1 = getProduct2(new ConcreteFactory1());p1.show();//product12-show()}
}interface AbstractFactory {public Product1 newProduct1();public Product2 newProduct2();
}class ConcreteFactory1 implements AbstractFactory {@Overridepublic Product1 newProduct1() {return new Product11();}@Overridepublic Product2 newProduct2() {return new Product12();}
}class ConcreteFactory2 implements AbstractFactory {@Overridepublic Product1 newProduct1() {return new Product21();}@Overridepublic Product2 newProduct2() {return new Product22();}
}interface Product1 {public void show();
}interface Product2 {public void show();
}class Product11 implements Product1 {@Overridepublic void show() {System.out.println("product11-show()");}
}class Product12 implements Product2 {@Overridepublic void show() {System.out.println("product12-show()");}
}class Product21 implements Product1 {@Overridepublic void show() {System.out.println("product21-show()");}
}class Product22 implements Product2 {@Overridepublic void show() {System.out.println("product22-show()");}
}

扩展

抽象工厂模式的扩展有一定的“开闭原则”倾斜性：

当增加一个新的产品族时只需增加一个新的具体工厂，不需要修改原代码，满足开闭原则。
当产品族中需要增加一个新种类的产品时，则所有的工厂类都需要进行修改，不满足开闭原则。

另一方面，当系统中只存在一个等级结构的产品时，抽象工厂模式将退化到工厂方法模式。

4.6 建造者模式

定义特点

建造者（Builder）模式的定义：指将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示，这样的设计模式被称为建造者模式。它是将一个复杂的对象分解为多个简单的对象，然后一步一步构建而成。它将变与不变相分离，即产品的组成部分是不变的，但每一部分是可以灵活选择的。

通过前面的学习，我们已经了解了建造者模式，那么它和工厂模式有什么区别呢？

建造者模式更加注重方法的调用顺序，工厂模式注重创建对象。
创建对象的力度不同，建造者模式创建复杂的对象，由各种复杂的部件组成，工厂模式创建出来的对象都一样
关注重点不一样，工厂模式只需要把对象创建出来就可以了，而建造者模式不仅要创建出对象，还要知道对象由哪些部件组成。
建造者模式根据建造过程中的顺序不一样，最终对象部件组成也不一样。

优缺点

该模式的主要优点如下：

封装性好，构建和表示分离。
扩展性好，各个具体的建造者相互独立，有利于系统的解耦。
客户端不必知道产品内部组成的细节，建造者可以对创建过程逐步细化，而不对其它模块产生任何影响，便于控制细节风险。

其缺点如下：

产品的组成部分必须相同，这限制了其使用范围。
如果产品的内部变化复杂，如果产品内部发生变化，则建造者也要同步修改，后期维护成本较大。

建造者（Builder）模式和工厂模式的关注点不同：建造者模式注重零部件的组装过程，而工厂方法模式更注重零部件的创建过程，但两者可以结合使用。

使用场景

建造者模式唯一区别于工厂模式的是针对复杂对象的创建。也就是说，如果创建简单对象，通常都是使用工厂模式进行创建，而如果创建复杂对象，就可以考虑使用建造者模式。

当需要创建的产品具备复杂创建过程时，可以抽取出共性创建过程，然后交由具体实现类自定义创建流程，使得同样的创建行为可以生产出不同的产品，分离了创建与表示，使创建产品的灵活性大大增加。

建造者模式主要适用于以下应用场景：

相同的方法，不同的执行顺序，产生不同的结果。
多个部件或零件，都可以装配到一个对象中，但是产生的结果又不相同。
产品类非常复杂，或者产品类中不同的调用顺序产生不同的作用。
初始化一个对象特别复杂，参数多，而且很多参数都具有默认值。

实现

建造者（Builder）模式的主要角色如下：

产品角色（Product）：它是包含多个组成部件的复杂对象，由具体建造者来创建其各个零部件。
抽象建造者（Builder）：它是一个包含创建产品各个子部件的抽象方法的接口，通常还包含一个返回复杂产品的方法 getResult()。
具体建造者(Concrete Builder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。
指挥者（Director）：它调用建造者对象中的部件构造与装配方法完成复杂对象的创建，在指挥者中不涉及具体产品的信息。

package com.atguigu.builder;
public class BuilderTest {public static void main(String[] args) {Builder builder1 = new ConcreteBuilder1();Director director = new Director(builder1);Product product = director.construct();product.show();}
}class Product {private String partA;private String partB;private String partC;public void setPartA(String partA) {this.partA = partA;}public void setPartB(String partB) {this.partB = partB;}public void setPartC(String partC) {this.partC = partC;}public void show() {//显示产品的特性System.out.println(this.toString());}@Overridepublic String toString() {return "Product{" +"partA='" + partA + '\'' +", partB='" + partB + '\'' +", partC='" + partC + '\'' +'}';}
}abstract class Builder {//创建产品对象protected Product product = new Product();public abstract void buildPartA();public abstract void buildPartB();public abstract void buildPartC();//返回产品对象public Product getResult() {return product;}
}class ConcreteBuilder1 extends Builder {public void buildPartA() {product.setPartA("建造 PartA,byBuilder1");}public void buildPartB() {product.setPartB("建造 PartB,byBuilder1");}public void buildPartC() {product.setPartC("建造 PartC,byBuilder1");}
}class ConcreteBuilder2 extends Builder {public void buildPartA() {product.setPartA("建造 PartA,byBuilder2");}public void buildPartB() {product.setPartB("建造 PartB,byBuilder2");}public void buildPartC() {product.setPartC("建造 PartC,byBuilder2");}
}class Director {private Builder builder;public Director(Builder builder) {this.builder = builder;}//产品构建与组装方法public Product construct() {builder.buildPartA();builder.buildPartB();builder.buildPartC();return builder.getResult();}
}

java设计模式(1)相关推荐

java备忘录模式应用场景_图解Java设计模式之备忘录模式
图解Java设计模式之备忘录模式游戏角色状态恢复问题游戏角色有攻击力和防御力,在大战Boss前保存自身的状态(攻击力和防御力),当大战Boss后攻击力和防御力下降,从备忘录对象恢复到大战前的状态. ...
JAVA 设计模式模板方法模式
定义模板方法模式 (Template Method) 定义了一个操作中的算法的骨架,而将部分步骤的实现在子类中完成. 模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤. 模 ...
Java设计模式之策略模式与状态模式
一.策略模式定义定义:策略模式定义了一系列的算法,并将每一个算法封装起来,而且使他们之间可以相互替换,策略模式可以在不影响客户端的情况下发生变化. 好了,定义看看就完了,我知道你很烦看定义. 二.策 ...
JAVA 设计模式享元模式
用途享元模式 (Flyweight) 运用共享技术有效地支持大量细粒度的对象. 享元模式是一种结构型模式. 结构图-享元模式结构图 Flyweight : 它是所有具体享元类的超类或接口,通过这个 ...
java设计模式观察者模式_理解java设计模式之观察者模式
在生活实际中,我们经常会遇到关注一个事物数据变化的情况,例如生活中的温度记录仪,当温度变化时,我们观察它温度变化的曲线,温度记录日志等.对于这一类问题,很接近java设计模式里面的"观察者模 ...
Java设计模式-七大设计原则
Java设计模式设计模式七大原则设计模式的目的编写软件过程中,程序员面临着来自耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性等多方面的挑战,设计模式是为了让程序(软件),具有更好代码 ...
Java设计模式(备忘录模式-解释器模式-状态模式-策略模式-职责链模式)
Java设计模式Ⅶ 1.备忘录模式 1.1 备忘录模式概述 1.2 代码理解 2.解释器模式 2.1 解释器模式概述 3.状态模式 3.1 状态模式概述 3.2 代码理解 4.策略模式 4.1 策略模 ...
Java设计模式（访问者模式-迭代器模式-观察者模式-中介者模式）
Java设计模式Ⅶ 1.访问者模式 1.1 访问者模式概述 1.2 代码理解 2.迭代器模式 2.1 迭代器模式概述 2.2 代码理解 3.观察者模式 3.1 观察者模式概述 3.2 代码理解 4.中 ...
Java设计模式(代理模式-模板方法模式-命令模式)
Java设计模式Ⅴ 1.代理模式 1.1 代理模式概述 1.2 静态代理 1.2.1 静态代理概述 1.2.2 代码理解 1.3 动态代理之JDK代理 1.3.1 动态代理之JDK代理概述 1.3.2 ...
Java设计模式（装饰者模式-组合模式-外观模式-享元模式）
Java设计模式Ⅳ 1.装饰者模式 1.1 装饰者模式概述 1.2 代码理解 2.组合模式 2.1 组合模式概述 2.2 代码理解 3.外观模式 3.1 外观模式概述 3.2 代码理解 4.享元模式 ...

java设计模式(1)

1、设计模式概述

1.1 介绍

1.2 分类

1.3 简要介绍23种设计模式的功能

2、UML

2.1 基本构件

2.1.1 事物

（1） 结构事物

（2）行为事物

（3）分组事物

（4）注释事物

2.1.2 图

类、接口、类图

2.1.3 关系

3、7种设计原则

3.1 开闭原则

定义

作用

实现

3.2 里氏替换

定义

作用

实现

3.3 依赖倒置

定义

作用

实现

3.4 单一职责

定义

作用

实现

3.5 接口隔离

定义

作用

实现

3.6 迪米特

定义

作用

实现

3.7 合成复用

定义

作用

实现

3.8 总结

4、23中设计模式介绍

代码复用

扩展性

如何正确使用设计模式？

创建型模式

4.1 单例模式

定义特点

优缺点

使用场景

实现

第 1 种：懒汉式单例(双重检查保证效率)

第 2 种：饿汉式单例

单例模式的扩展

4.2 原型模式

定义特点

优缺点

使用场景

实现

浅克隆

深克隆

方法一：重写clone

方法二：通过对象序列化

原型模式的扩展

工厂模式

4.3 简单工厂模式

定义特点

优缺点

使用场景

实现

4.4 工厂方法模式

定义特点

优缺点

使用场景

实现

4.5 抽象工厂模式

（1）结构事物