Week 3 作业 02



一个设计模式的四个部分：

• 模式的名称 － 由少量的字组成的名称，有助于我们表达我们的设计。

• 待解问题 － 描述了何时需要运用这种模式，以及运用模式的环境（上下文）。

• 解决方案 － 描述了组成设计的元素（类和对象）、它们的关系、职责以及合作。但这种解 决方案是抽象的，它不代表具体的实现。

• 结论 － 运用这种方案所带来的利和弊。主要是指它对系统的弹性、扩展性、和可移植性的影响。



设计模式的分类 从功能分

• 创建模式（Creational Patterns）

• 对类的实例化过程的抽象。

• https://www.jianshu.com/p/a33f0b96d96a

• 结构模式（Structural Patterns）

• 将类或者对象结合在一起形成更大的结构。

• https://www.jianshu.com/p/ca13ce2753af

• 行为模式（Behavioral Patterns）

• 对在不同的对象之间划分责任和算法的抽象化。

• https://design-patterns.readthedocs.io/zh_CN/latest/behavioral_patterns/behavioral.html



从方式分

• 类模式

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

• 对象模式

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



简单工厂的优缺点

优点：

• 使 Client 不再依赖 Sorter 的具体实现（如 BubbleSorter）

• 对 Client 实现 OCP － 增加 Sorter 不影响 Client

• 克服了简单工厂违背开放-封闭原则的缺点，又保留了封装对象创建过程的优点,降低客户端和工厂的耦合性，所以说“工厂模式”是“简单工厂模式”的进一步抽象和推广。

缺点：

• 对 Factory 未实现 OCP － 增加 Sorter 需要修改 Factory

• 每增加一个产品，相应的也要增加一个子工厂，加大了额外的开发量。

https://blog.csdn.net/tian_yan71/article/details/78843900

https://blog.csdn.net/qq_17555933/article/details/102867928



改进一所存在的问题

解决了 Factory 的 OCP 问题吗？

• 增加 Sorter 实现时，不需要修改 Factory 了

• 但是仍然需要修改 Client

其它问题

• 丧失了编译时的类型安全 Ø Client 和 Factory 均类型不安全

• Client 仍然“知道”Sorter 的实现是什么

• 限制了 Sorter 的实现只能通过“默认构造函数”创建

改进二的优缺点

优点

• 满足 OCP？

• 对 Client 和 Factory 均满足

• 满足 OCP 方法

• 抽象

• 动态编程（即将编译时类型检查转变成运行时检查）

缺点

• 缺少编译时类型安全

• 限制了 Sorter 的实现只能通过“默认构造函数”创建

• 假如需要传递参数？

这种做法其实相当重要

• 简单工厂非常重要，是许多其它模式的基础

• 而该机制解决了简单工厂模式最致命的问题



为什么要使用 Singleton 模式保证产生单一实例，就是说一个类只产生一个实例。使用 singletong 有 两个原因：

• 是因为只有一个实例，可以减少实例频繁创建和销毁带来的资源消耗；

• 是当多个用户使用这个实例的时候，便于进行统一控制（比如打印机对象）。

• https://www.runoob.com/design-pattern/singleton-pattern.html

前者是性能需求，后者是功能需求。



适配器的作用 系统需要使用现有的类，而这个类的接口与我们所需要的不同

• 例如：我们需要对 List 进行排序，但是我们需要一个 Sortable 接口，原有的 List 接口不能 满足要求。

实现一个单元测试的步骤 创建测试类，从 TestCase 派生 初始化

• 覆盖基类的方法：protected void setUp() 清除环境

• 覆盖基类的方法：protected void tearDown() 书写测试方法

• 命名规则：public void testXyz()



模板方法模式（Template Method） 模板方法模式是扩展功能的最基本模式之一

• 它是一种“类的行为模式” 它是通过“继承”的方法来实现扩展

• 基类负责算法的轮廓和骨架 • 子类负责算法的具体实现 组合 vs. 继承

• 基于“继承”的模板方法比“组合”更容易实现

• 在很多情况下，可以适当使用这种模式。



模板方法的形式 抽象方法

• protected abstract void step1();

• 强制子类实现该步骤。 具体方法

• protected void doSomething() { … }

• 子类不需要覆盖，但也可以覆盖之。

• 如想明确告诉子类“不要覆盖它”，最好标明：final 钩子方法

• protected void setUp() { }

• 空的实现（缺省适配器模式）

• 子类可选择性地覆盖之，以便在特定的时机做些事。





什么时候使用策略模式？ 系统需要在多种算法中选择一种 重构系统时，

• 将条件语句转换成对于策略的多态性调用 策略模式的优点（对比模板方法）

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

• 策略对象可以自由组合 策略模式可能存在的问题：

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