一：一个目标
二：两种手段
三：八大原则
（一）依赖倒置原则（DIP）
（二）开放封闭原则（OCP）
（三）单一职责原则（SRP）
（四）里氏替换原则（LSP）（多态）
（五）接口隔离原则（ISP）
（六）优先使用对象组合，而不是类继承
（七）封装变化点
（八）迪米特法则：针对接口编程，而不是针对实现编程
四：重构技法
静态 -> 动态
早绑定 -> 晚绑定
继承 -> 组合
编译时依赖 -> 运行时依赖
紧耦合 -> 松耦合
五：从封装变化角度对模式分类
红色圈出的：用的不多，甚至有的设计模式过时了。其他部分在工作中十分常用
六：类图对比
对比所有模式的类图，几乎所有模式的结构都归属到：下面第三种类型
继承转组合，慎用继承，多用组合。其中组合是指第三种，使用指针，联系多态，间接关联，松耦合，灵活性高
七：关注变化点和稳定点
设计模式，一般不考虑极端情况（实际中会出现，但是不会太多），一般软件稳定性都满足状态分布
八：什么时候不用模式
代码可读性很差时：变量命名，函数逻辑是否清晰，类的划分是否足够清晰，模式是在这些都完成后才去使用的，而不是一开始就使用
需求理解很差时：项目开始时，客户需求不理解，朦胧。先排除部分需求，一般软件第一版对设计模式并没有直接感觉
变化没有显现时：不要乱用，变化没有显现就不要用
不是系统的关键依赖点：不是关键结构，没必要
项目没有复用价值时：以后不需要我们维护时，但是对于产品型，我们要出多个版本，我们使用设计模式后代码修改会变少，维护方便，因为需求变更而做的变化会少很多
项目将要发布时：模式需要重构，一步步分析，要是因为使用模式而引入一些bug，得不偿失。
九：经验之谈
不要为模式而模式
关注抽象类&接口（基类比子类更加有用）
理清变化点和稳定点
审视依赖关系
要有Framework<设计模式要求更高> 和 Application 的区隔思维（分清角色，Framework留扩展点，Application使用扩展点）
良好的设计是演化的结果，（不是一步到位，迭代重构而来，往往需要更多时间）
十：设计模式成长之路（4阶段）
