就一个类而言，应该仅有一个引起它的变化的原因
原则
最简单，最单纯的事情最容易控制，最有效
类的职责简单而且集中，避免相同的职责分散到不同的类之中，避免一个类承担过多的职责
减少类之间的耦合
当需求变化时，只修改一个地方
组件
每个组件集中做好一件事情
组件的颗粒度
发布的成本
可重用的成本
方法
避免写臃肿的方法
Extract Method
重构
Move Field/Move Class
Extract Method/Extract Class
最简单的，也是最难以掌握的原则
实例分析
Olite
开放封闭原则——OCP
软件实体（类，模块，函数）应该是可以扩展的，但是不可修改的
原则
对扩展是开放的，当需求改变时我们可以对模块进行扩展，使其具有新的功能
对更改是封闭的，对模块扩展时，不需要改动原来的代码
面对抽象而不是面对细节，抽象比细节活的更长
僵化的设计——如果程序中一处改动产生连锁反应。
对更改是封闭的，对模块扩展时，不需要改动原来的代码
面对抽象而不是面对细节，抽象比细节活的更长
僵化的设计——如果程序中一处改动产生连锁反应。
方法
条件case if/else 语句
重构
Replace Type Code With Class
Replace Type Code With State/Strategy
Replace Conditional with polymorphism
实例
插件
数据驱动的OrderCycle
Liskov替换原则 LSP
子类型必须能够替换它的基类型
原则
主要针对继承的设计原则
所有派生类的行为功能必须和客户程序对其基类所期望的保持一致。
派生类必须满足基类和客户程序的约定
IS-A是关于行为方式的，依赖客户程序的调用方式
重构
Extract Supper Class
实例
长方形和正方形
依赖倒置原则DIP
a：高层模块不应依赖于底层模块，两者都应该依赖于抽象
b：抽象不应该依赖于细节，细节应该依赖于抽象
原则
如何解释倒置
高层依赖底层，重用变得困难，而最经常重用的就是framework和各个独立的功能组件
高层依赖底层，底层的改动直接反馈到高层，形成依赖的传递
面向接口的编程
实例
Ioc模式
DomainObject / DomianObjectDataService
参考
《敏捷软件开发 原则、模式与实践》
