1. 设计模式简介

课程目标

• 理解松耦合设计思想
• 掌握面向对象设计原则
• 掌握重构技法改善设计
• 掌握GOF 核心设计模式

什么是设计模式

“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。”

GOF 设计模式

• 历史性著作《设计模式：可复用面向对象软件的基础》一书中描述了23种经典面向对象设计模式，创立了模式在软件设计中的地位。
  可复用是一个设计目标，面向对象是手法
• 由于《设计模式》一书确定了设计……
  还有其他的模式
  架构模式
  数据库模式

从面向对象谈起

• 底层思维：向下，如何把握机器底层从微观理解对象构造
  • 语言构造
  • 编译转换
  • 内存模型
  • 运行时机制
• 抽象思维：向上，如何将我们的周围世界抽象为程序代码
  • 面向对象
  • 组建封装
  • 设计模式
  • 架构模式

深入理解面向对象

• 向下：深入理解三大面向对象机制
  • 封装，隐藏内部实现
  • 继承，复用现有代码
  • 多态，改写对象行为
• 向上：深刻把握面向对象机制所带来的抽象意义，理解如何使用这些机制来表达现实世界，掌握什么是“好的面向对象设计”
  评判好坏要看抽象机制

软件设计固有的复杂性

建筑商从来不会去想给一栋已建好的100层高的楼房底下再新修一个小地下室……

软件设计复杂的根本原因

变化

• 客户需求的变化
• 技术平台的变化
• 开发团队的变化
• 市场环境的变化
  ……

如何解决复杂性？

• 分解
  人们面对复杂性有一个常见的做法：即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。
• 抽象
  更高层次来讲，人们处理复杂性有一个通用的技术，即抽象出由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去处理泛化和理想化了的对象模型。

重要的建立一些思想和模型。

举例

Shape1（分解）
Shape2（抽象）
基类最好要有虚的析构函数。
所有继承最好都要用public的继承。
多态性->指针
第一种如果要变更，需要在所有涉及的地方修改。
第二种如果要变更，如果使用工厂模式，只需要增加一个子类。重用性得到了很高的提升。

软件设计的目标

什么是好的软件设计？软件设计的金科玉律：

复用！

2. 面向对象设计原则

面向对象设计，为什么？

变化是复用的天敌！
面向对象设计最大的优势在于：

抵御变化

重新认识面向对象

• 理解隔离变化
  • 从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小。
• 各司其职
  • 从微观层面来看，面向对象的方式更强调各类的“责任”
  • 适用于需求变化导致的新增类型不应该影响原来类型的实现——是所谓各负其责
• 对象是什么？
  • 从语言实现层面来看，对象封装了代码和数据。
  • 从规格层面讲，对象是一系列可被使用的公共接口。
  • 从概念层面讲，对象是某种拥有责任的抽象。

面向对象设计原则（1/8）

• 以来倒置原则（DIP）
  • 高层模块（稳定）不应依赖于低层模块（变化），二者应该依赖于抽象（稳定）。
  • 抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）。

MainForm（依赖）->Line Rect
MainForm（依赖）->Shape<-（依赖）Line Rect

面向对象设计原则（2）

• 开放封闭原则（OCP）
  • 对扩展开放，对更改封闭。
  • 类模块应该是可扩展的，但是不可修改。

面向对象设计原则（3）

• 单一职责原则（SRP）
  • 一个类应该仅有一个引起它变化的原因。
  • 变化的方向隐含着类的责任。

面向对象设计原则（4）

• Liskov替换原则（LSP）
  • 子类必须能够替换它们的基类（IS-A）。
  • 继承表达类型抽象。

面向对象设计原则（5）

• 接口隔离原则（ISP）
  • 不应该强迫客户依赖它们不用的方法。
  • 接口应该小而完备。

一旦产生依赖，就必须保持稳定。

面向对象设计原则（6）

• 优先使用对象组合，而不是类继承
  • 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。
  • 继承在某种程度上破坏了封装性，子类父类耦合度高。
  • 而对象组合则要求被组合的对象具有良好定义的接口耦合度低。

面向对象设计原则（7）

• 封装变化点
  使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良影响从而实现层次间的松耦合。

面向对象设计原则（8）

• 针对接口编程，而不是针对实现变成
  • 不将变量类型声明为某个特定的具体类，而是声明为某个接口。
  • 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
  • 减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。

面向接口设计

产业强盛的标志

接口标准化！

分工协作，通过分工实现复用性。

以史为鉴（1）

秦为什么能够统一六国？
根据史书记载和考古发现，秦的兵器不论东南西北，出土地点都有统一的标准，包括剑，戈，弩，甚至弩机，弩体，箭头都是一样的。而其他六国则不是。

以史为鉴（2）

毕升的活字印刷为什么成为四大发明，推动了人类文明的前进？
毕升之前的雕版印刷将字刻死在木板或石板上……

将设计原则提升为设计经验

1. 设计习语 Design Idioms
   Design Idioms 描述与特定编程语言相关的低层模式，技巧，惯用法。
2. 设计模式 Design Patterns
   Design Patterns 主要描述的是“类与相互通信对象之间的组织关系，包括它们的角色、职责、协作方式等方面。
3. 架构模式 Architectural Patterns
   Architectural Patterns 描述系统中与基本结构组织关系密切的高层模式，包括子系统划分，职责，以及如何组织它们之间关系的规则。

3. 模板方法 Template Method

GOF-23 模式分类

• 从目的来看：
  • 创建型（Creational）模式：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体类型实现引来的冲击。
  • 结构型（Structural）模式：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击。
  • 行为型（Behavioral）模式：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击。
• 从范围来看：
• 类模式处理类与子类的静态关系。（集成）
• 对象模式处理对象间的动态关系。 （组合）

从封装变化角度对模式分类

• 组件协作：
  • Template Method
  • Strategy
  • Observer/Event
• 单一职责：
  • Decorator
  • Bridge
• 对象创建：
  • Factory Method
  • Abstract Factory
  • Prototype
  • Builder
• 对象性能：
• Singleton
• Flyweight
• 接口隔离：
  • Facade
  • Proxy
  • Mediator
  • Adapter
• 状态变化：
  • Memento
  • State
• 数据结构：
  • Composite
  • Iterator
  • Chain of Responsibility
• 行为变化：
  • Command
  • Visitor
• 领域问题：
  • Interpreter

重构获得模式 Refactoring to Patterns

• 面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”指的是那些可以满足“应对变化，提高复用”的设计。
• 现代软件设计的特征是“需求的频繁变化”。设计模式的要点是“寻找变化点，然后在变化点处应用设计模式，从而来更好地应对需求的变化”。“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。
• 设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

推荐图书

重构——改善既有代码的设计
Refactoring to Patterns 重构与模式

重构关键技法

• 静态 → 动态
• 早绑定 → 晚绑定
• 继承 → 组合
• 编译时依赖 → 运行时依赖
• 紧耦合 → 松耦合

是从不同角度谈一个问题

“组件协作”模式：

• 现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，使二者之间协作时常用的模式。
• 典型模式
  • Template Method
  • Strategy
  • Observer / Event

Template Method

动机（Motivation）

• 在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。
• 如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？

基类一定要写虚的析构函数

结构化软件设计流程 面向对象软件设计流程 早绑定与晚绑定

常见方式

将过程写到库中，过程中留有虚函数，在复用时定义虚函数。
纵向的灵活性。

模式定义

定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中。Template Method 使得子类可以不改变（复用）一个算法的结构即可重定义（override 重写）该算法的某些特定步骤。
——《设计模式》Gof
稳定是指的相对稳定，变化只是相对不稳定。

结构（Structure）

结构（Structure）

TemplateMethod() 稳定
PrimitiveOperation() 变化
每次遇到Lib，都要知道哪些是稳定的部分，哪些是不稳定的部分。

要点总结

• Template Method 模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点（继承+多态），是代码复用方面的基本实现结构。
• 除了可以灵活应对子步骤的变化外，“不要调用我，让我来调用你”的反向控制结构是 Template Method 的典型应用。
• 在具体实现方面，被 Template Method 调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为 protected 方法。

4. 策略模式

策略模式（Strategy）

动机（Motivation）

• 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。
• 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？

多态性就要求指针必须可以指向多种类，不是一个确定的类，引用不可以。

模式定义

定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（扩展，子类化）。
——《设计模式》Gof

常见方式

构建一个基类，多个子类。
构建一个类，引用这个基类，并在函数中由其他参数决定使用哪个子类。
横向的自由度。

结构（Structure）

Context和Strategy稳定
ConcreteStrategy变化

要点总结

• Strategy 及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。
• Strategy 模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条判断语句的代码通常都需要Strategy模式。
• 如果Strategy 对象没有实例变量，那么各个上下文可以共享同一个Strategy 对象，从而节省对象开销。

Observer 观察者模式

动机（Motivation）

• 在软件构架过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。
  *使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。

多继承可以是一个继承基类，以及多个继承接口

模式定义

定义对象间的一种一对多（变化）的依赖关系，以便当一个对象（Subject）的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。
——《设计模式》Gof

结构（Structure）

Subject和Observer是稳定的
ConcreteSubject和CencreteObserver是变化的

常见方法

构建一个消息类，在基类中建立其List表，然后由其他对象获取其状态。

要点总结

• 使用面向对象的抽象，Observer 模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达至松耦合。
• 目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。
• 观察者自己决定是否需要订阅通知，目标对象对此一无所知。
• Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。

这是一种非常常用的模式。

“单一职责”模式：

• 在软件组件的设计中，如果职责划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。
• 典型模式
  • Decorator
  • Bridge

Decorator 装饰模式

动机（Motivation）

• 在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。
• 如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？

一般结构 装饰结构

组合优于继承

NetworkStream::Read(number);//继承实现，静态特质
stream->Read(number);//组合实现，动态特质，可以改变
···
### 模式定义
动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码&减少子类个数）。
——《设计模式》GoF

![结构（Structure）](https://img.haomeiwen.com/i4119448/9f6b4cceeffe7984.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

Component Decorator 稳定
ConcreteConment ConcreteDecorator 变化

### 要点总结
* 通过采用组合而非继承的首发，Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
*  Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实际上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。
* Decorator 模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

## Bridge 桥模式
### 动机（Motivation）
* 由于某些类型的固有的实现逻辑，使得他们具有两个变化的维度，乃至多个维度的变化。
* 如何应对这种“多个维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？

### 模式定义
将抽象部分（业务功能）与实现部分（平台实现）分离，使它们都可以独立地变化。
——《设计模式》 GoF

![结构（Structure）](https://img.haomeiwen.com/i4119448/57b1fd891e09c501.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
Abstraction Implementor 稳定
RefinedAbstraction ConcreteImplementor 变化

### 要点总结
* Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自的维度的变化，即“子类化”它们。
* Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
* Bridge模式的应用一般在“两个非常强的变化维度”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。