极客时间架构师培训 1 期 - 第 3 周总结

万事万物皆有规律，天有道，程序也有道

设计模式

开发设计的软件复用能力的解决方案

功能划分：

• 创建模式 Creational Patterns 对类的实例化过程的抽象

• 结构模式 Structural Patterns 将类或者对象结合在一起形成更大的结构

• 行为模式 Behavioral Patterns 对在不同的对象之间划分责任和算法的抽象化、

方式划分：

• 类模式 以继承的方式实现模式，静态的

• 对象模式 以组合的方式实现模式，动态的

简单工厂模式

创建模式

许多其他模式的基础

思考： 事情都要有规划管理，要三思而后行

场景： 类实例化场景

单例模式

思考：要充分利用身边已有的资源，不要重复造轮子。

场景：1、性能场景，避免过多的对象创建与销毁过程，资源浪费；2、应用场景要求，便于统一控制，例如打印场景

实现：通常与简单工厂模式（通过动态配置文件方式）结合使用

• 饿汉方式

• 懒汉方式（线程安全版）

• 双检锁/双重校验锁（DCL, double-checked locking)

• 登记式/静态内部类：这种方式能达到双检锁方式一样的功效，但实现更简单。对静态域使用延迟初始化，应使用这种方式而不是双检锁方式。这种方式只适用于静态域的情况，这种方式利用了 classloader 机制来保证初始化 instance 时只有一个线程，这种方式是 Singleton 类被装载了，instance 不一定被初始化。因为静态内部类类没有被主动使用，只有通过显式调用 getInstance 方法时，才会显式装载 静态内部类类，从而实例化 instance。想象一下，如果实例化 instance 很消耗资源，所以想让它延迟加载，另外一方面，又不希望在 Singleton 类加载时就实例化，因为不能确保 Singleton 类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化 instance 显然是不合适的，可以采用这种方式

• 枚举方式：这种实现方式还没有被广泛采用，但这是实现单例模式的最佳方法。它更简洁，自动支持序列化机制，绝对防止多次实例化。这种方式是 Effective Java 作者 Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还自动支持序列化机制，防止反序列化重新创建新的对象，绝对防止多次实例化。不过，由于 JDK1.5 之后才加入 enum 特性，用这种方式写不免让人感觉生疏，在实际工作中，也很少用。不能通过 reflection attack 来调用私有构造方法。

适配器模式

结构模式，兼爱模式

思考：做成事情有时不一定要走一条顺畅的直路，有时候也需要迂回会更好；进退有度，全面考虑

场景：系统需要使用现有的类，而这个类的接口与我们所需要的不同

模板模式

类的行为模式，通常与策略模式结合使用

思考：万事万物皆有一定规则，有时候道理是相通的；不论社会还是自然宇宙；

场景：行为模式比较固定，实现比较多样的场景

实现：它是通过“继承”的方法来实现扩展，静态

• 基类负责算法的轮廓和骨架

• 子类负责算法的具体实现

形式：

• 抽象方法，强制子类来实现

• 具体方法，子类可以覆盖，也可不覆盖；明确不能覆盖，可用final关键字

• 钩子方法，空方法实现，子类选择性覆盖（适当时机覆盖）

策略模式

对象的行为模式，通常与模板模式结合使用

思考：做人做事要灵活，不能总是一根筋；需要因时因地因人而定

场景：系统需要在多种算法中选择一种，静态

• 重构系统时，将条件语句转换成对于策略的多态性调用

实现：它是通过“组合”的方法来实现扩展

优点（对比模板方法）

• 将使用策略的人与策略的具体实现分离（应用与实现分离）

• 策略对象可以自由组合

缺点：策略模式仅仅封装了“算法的具体实现”，方便添加和替换算法。但它并不关心何时使用何种算法，这个必须由客户端来决定

组合（合成）模式

对象的结构模式；具备统一接口；主要解决树形结构问题

思考：团队合作，需要互相协助；家和万事兴

场景：功能对象需要多个相同接口的对象实现协作完成；如AWT控件；

装饰器模式

包装器，对象的结构模式，扩展外围功能

思考：工作生活中，事情都可以做的更好一点，尽管没有完美；但要避免华而不实

场景：在不改变对客户端的接口的前提下，对现有功能进行包装强化

特点：

• 在不改变对客户端的接口的前提下（对客户端透明）

• 扩展现有对象的功能

• 区别在于适配器是转换成另一个接口，而装饰器是保持接口不变

• 包装器形成一条“链”

对比：

• 装饰器和模板方法、策略模式的比较

装饰器保持对象的功能不变，扩展其外围的功能；

模板方法和策略模式则保持算法的框架不变，而扩展其内部的实现

• 装饰器和继承的比较

都可以用来扩展对象的功能

装饰器是动态的，继承是静态的

装饰器可以任意组合，但这也使装饰器更复杂，有可能会组合出荒谬的结果

依赖注入DI与控制反转IOC、

思考：自立更生，才是永恒之道、

特点：主要实现对象关系的解耦，引入IOC容器，实现对象之间关系的控制反转

Spring mvc模式

思考：团队需要分工明确，否则，混乱无序

特点：WEB应用

管道模式

之所以加上这个模式，是因为鄙人在实际目前工作中用的还是比较频繁；这也是我在了解tomcat原理的时候实际体会最深的一种设计模式。

思考：任何事情都是循序渐进的，无序只能造成混乱。

场景：管道模式是多步流程业务很好的抽象，内部基于单链表实现顺序执行，具有强顺序性；

管道模式对于整体流程的拆分，使得业务的扩展性大大增强，当业务需求发生变化，只需要确定需要加入/删除的子流程位置即可，就像从单链表中增加/删除一个节点。