一个目标
管理变化，提高复用
两种手段
分解 vs 抽象
八大原则
依赖倒置原则
开放封闭原则
单一指责原则
Liskov替换原则
接口隔离原则
对象组合优于继承
封装变化点
面向接口编程
原则比具体的设计模式更重要，内化原则
重构技法
静态 —> 动态
早绑定 —> 晚绑定
继承 —> 组合
编译时依赖 —> 运行时依赖
紧耦合 —> 松耦合
从封装变化的角度对模式分类
像Builder,Mediator等一些设计模式在平时用的不多，也有些是因为C++在语言特性上的进步使得某些模式的使用性价比不高。
C++对象模型
以上的设计模式最后都殊途同归，如第三种对象模型，都是通过一个指针指向一个多态对象表达灵活性。
关注变化点与稳定点
当软件中所有部分都处于变化之中，就没有设计模式能解决，当软件中所有部分都稳定，也没有必要使用设计模式。当然这两种极端的情况很少会出现，一般的软件的稳定与变化是呈正态分布的，
什么时候不用设计模式
代码可读性很差时
需求理解还很浅时
变化没有显现时
不是系统的关键依赖点
项目没有复用价值时
项目将要发布时
代码可读性是软件最基础的质量保证，模式是在基础工作做好之后才用的。
经验之谈
不要为模式而模式
关注抽象类&接口
理清变化点和稳定点
审视依赖关系
要有Framework和Application的区隔思维
良好的设计是演化的结果
设计模式成长之路
“手中无剑，心中无剑”：见模式而不知
“手中有剑，心中无剑”：可以识别模式，作为应用开发人员使用模式
“手中有剑，心中有剑”：作为框架开发人员为应用设计某些模式
“手中无剑，心中有剑”：忘掉模式，只有原则