设计模式总结

一：一个目标

管理变化，提高复用

二：两种手段

 分解 VS 抽象

三：八大原则

　　（一）依赖倒置原则（DIP）
  （二）开放封闭原则（OCP）
  （三）单一职责原则（SRP）
  （四）里氏替换原则（LSP）（多态）
  （五）接口隔离原则（ISP）
  （六）优先使用对象组合，而不是类继承
  （七）封装变化点
  （八）迪米特法则：针对接口编程，而不是针对实现编程

原则比模式更重要

四：重构技法

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

五种技法，相通

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

红色圈出的：用的不多，甚至有的设计模式过时了。其他部分在工作中十分常用

六：类图对比

对比所有模式的类图，几乎所有模式的结构都归属到：下面第三种类型

继承转组合，慎用继承，多用组合。其中组合是指第三种，使用指针，联系多态，间接关联，松耦合，灵活性高

七：关注变化点和稳定点

设计模式，一般不考虑极端情况（实际中会出现，但是不会太多），一般软件稳定性都满足状态分布

八：什么时候不用模式

代码可读性很差时：变量命名，函数逻辑是否清晰，类的划分是否足够清晰，模式是在这些都完成后才去使用的，而不是一开始就使用

需求理解很差时：项目开始时，客户需求不理解，朦胧。先排除部分需求，一般软件第一版对设计模式并没有直接感觉

变化没有显现时：不要乱用，变化没有显现就不要用

不是系统的关键依赖点：不是关键结构，没必要

项目没有复用价值时：以后不需要我们维护时，但是对于产品型，我们要出多个版本，我们使用设计模式后代码修改会变少，维护方便，因为需求变更而做的变化会少很多

项目将要发布时：模式需要重构，一步步分析，要是因为使用模式而引入一些bug，得不偿失。

九：经验之谈

不要为模式而模式

关注抽象类&接口（基类比子类更加有用）

理清变化点和稳定点

审视依赖关系

要有Framework<设计模式要求更高> 和 Application 的区隔思维（分清角色，Framework留扩展点，Application使用扩展点）

良好的设计是演化的结果，（不是一步到位，迭代重构而来，往往需要更多时间）

十：设计模式成长之路（4阶段）