设计模式总结

第一讲：设计模式简介

什么是设计模式

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

如何解决复杂性

1.分解
即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。分解是人们面对复杂性时的常见做法
2.抽象
由于不能掌握全部的复杂对象，从而选择忽视它的非本质细节而去处理泛化和理想化的对象模型。抽象是处理复杂性的更高层次的解决方案，也是通用的技术

软件设计的目标：复用

第二讲：面向对象原则

变化是复用的天敌，面向对象设计的最大优势在于 “抵御变化” ！

重新理解面向对象

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

面向对象设计八大原则

依赖倒置原则（DIP）

• 高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)
• 抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)

开放封闭原则（OCP）

• 对扩展开放，对更改封闭
• 类模块应该是可扩展的，但是不可修改

单一职责原则（SRP）

• 一个类应该仅有一个引起它变化的原因
• 变化的方向隐含着类的责任

Liskov 替换原则（LSP）

• 子类必须能够替换它们的基类(IS-A)
• 继承表达类型抽象

接口隔离原则（ISP）

• 不应该强迫客户程序依赖它们不用的方法
• 接口应该小而完备

优先使用对象组合，而不是类继承

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

封装变化点

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

针对接口编程，而不是针对实现编程

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

产业强盛的标志：接口标准化！

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

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

设计模式分类

从目的来看：

• 创建型模式：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体实现引来的冲击
• 结构型模式：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击
• 行为型模式：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击

从范围来看

• 类模式处理类与子类的静态关系（更偏向于继承方案）
• 对象模式处理对象间的动态关系（更偏向于对象组合方案）

从封装变化角度进行分类

• 组件协作：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 PaPatterns）》

重构关键技法

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

八大原则、重构技法、模式分类

现代较少用的模式： Builder、Mediator、Memento、Iterator、Chain of Resposibility、Command、Visitor、 Interpreter

关注变化点和稳定点：设计模式-隔离变化点和稳定点

什么时候不用模式

– 代码可读性差时
– 需求理解还很浅时
– 变化还没有显现时
– 不是系统的关键点时
– 项目没有复用价值时
– 项目将要发布时

经验之谈

– 不要为模式而模式
– 关注抽象类 & 接口
– 理清变化点和稳定点
– 审视依赖关系
– 要有 Framework 和 Application 的区隔思维
– 良好的设计是演化的结果（不是一步到位的）

设计模式成长之路

– “手中无剑，心中无剑”：见模式而不知
– “手中有剑，心中无剑”：可以识别模式，作为应用开发人员使用模式
– “手中有剑，心中有剑”：作为框架开发人员为应用设计某些模式
– “手中无剑，心中有剑”：忘掉模式，只有原则