总结【设计模式】

1 一个目标
管理变化，提高复用

2 两个手段
分解vs抽象

3 八大原则
依赖倒置原则（DIP）
高层模块（稳定）不应该依赖于底层模块（变化），二者都依赖于抽象（稳定）。 高层模块 - 抽象 - 底层模块
抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定） 抽象 - 实现细节
开放封闭原则（OCP）
对扩展开放，对更改封闭
类模块应该是可扩展的，但是不可修改
单一职责原则（SRP）
一个类应该仅有一个引起它变化的原因。
变化的方向隐含着类的责任。
Liskov替换原则（LSP）
子类必须能够替换它们的基类（is a）
基层表达类型抽象
接口隔离原则（ISP）
不应该强迫客户程序依赖它们不用的方法
接口应该小而完备
对象组合优于类继承
类继承为“白盒复用”，对象组合通常为“黑盒复用”
继承在某种程度上破坏了封装性，子类父类耦合度高
而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。
封装变化点
面向接口编程
客户程序无需获知对象的具体类型，只需要知道对象所具有的接口

4 重构技法
静态->动态
早绑定->晚绑定
继承->组合
编译时依赖->运行时依赖
紧耦合->松耦合

5 从封装变化角度对模式分类
组件协作：
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（不常用）

6 C++对象模型
class A: B {}; B|A  紧耦合
class A{B b;}; B|A  紧耦合
class A{B* pb;}; A|p -->B   松耦合

7 关注变化点和稳定点
稳定点是缺点，稳定点变不稳定就是失败的模式使用

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

9 经验之谈
不要为模式而模式
关注抽象类&接口
理清变化点和稳定点
审视依赖关系
要有Framework和Application的区隔思维
良好的设计是演化的结果