敏捷软件开发：原则、模式与实践-读书笔记1

单一职责链原则（SRP）：
为何要把两个职责分类到单独的类中：因为每一个职责都是变化的轴线，当需求变化时，改变化会反应为类的职责的变化，如果一个类承担了多于一个的职责，那么引起他变化的原因就会有多个；维度越多，责任越大，越不好控制
如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱设计，当发生变化时，设计会遭受到意想不到的破坏。责任在一个类中的耦合会导致，类中存在错综交杂的关系线，一旦某个节点的变动可能会引起额外的未测试到的问题。
如果能够想到多于1个的动机去改变一个类，那么这个类就具有多于一个职责，我们习惯于以组的形式去考虑职责。职责组是否应该分开，这 依赖于应用程序的变化方式，如果应用程序的变化方式会影响连接函数的签名，那么这个 设计就具有僵化性的臭味，因为调用的类必须重新编译，部署的次数常常会超过我们希望的次数，在这种情况下，就应该分离多个职责。一个职责的变化引起其他类的变动，建议拆分职责组。另一方面，如果应用程序的变化总是导致这两个职责同时变化，那么就不应该分离他们。
常见的违反单一职责的情形。某类同时包含了业务规则和持久化的控制。这两个职责在大多数情况下 决不 应该混合在一起的，业务规则往往会频繁的变化，而持久化的变化确不会如此频繁的变化，并且变化的原因也是完全不相同的，把业务和持久化子系统绑定在一起的做法是不合理的。
建议使用Facede或则proxy模式对设计进行重构，分离职责。

开发-封闭原则（OCP）
软件实体（类，模块，函数等等）应该是可以扩展的，但是不可修改的。
如果程序中一处改动就会产生连锁反应，导致一系列相关模块的改动，那么设计就具有僵化性的臭味。如果正确的应用OCP，那么以后的改动在进行相同的改动时，就只需要添加新的代码，而不必改动已经运行正常的代码。
对扩展是开放的，这意味着模块的行为是可扩展的，当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为，换句话说，我们可改变模块的功能。对更改时封闭的，多模块行为进行扩展时，不必改动模块的源代码或者二进制代码，模块的二进制可执行版本无论是可连接的库，dll或者java的jar文件，都无需改动。已经生的二进制文件都无需改动。
如何去隔离变化呢，我们会在可能变化的地方放置吊钩（hock），然而我们放置吊钩常常是错误的。通常，我们更原因一直等到确实需要那些抽象的对象时再把它放置进去。

Liskov替换原则（LSP）
子类型必须能够替换掉他们的基类型；
我们经常说继承是IS-A的关系，也就是说，如果一个新类型的对象被对象认知为和一个已有类的对象满足IS-A关系，那么这个新的对象类应该从这个已有对象派生。
如果一组类都支持一个公共的职责，那么他们应该从 一个公共的超类继承该职责，如果公共的超类还不存在，那么创建一个，并把公共的职责放入其中。毕竟，这样的一个类的有用性是确定无疑的-你已经提示了一些类会继承这些 职责，然而稍后对系统的扩展也许会加入一个新的子类，该子类很可能会以新的方式来支持同样的职责，此时，创建的超类可能是一个抽象类。提取公共的职责作为超类的原则。

依赖倒置原则（DIP）
高层模块不应该依赖于低层模块，二者都应该依赖于抽象
抽象不应该依赖于细节，细节应该依赖于抽象。
较为合适的模型，每个较高层次都为它所需要的服务申明一个抽象接口，较低的层次实现了这些抽象接口，每个高层类都通过该抽象接口使用下一层的，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。请注意这里的倒置不仅仅是依赖关系的倒置，他也是接口所有权的倒置。
低层模块实现了在高层模块中声明并被高层模块的调用的接口。
DIP的解释，依赖于 抽象，该启发规则建议不应该依赖于具体的类，也就是说，程序中所有的依赖关系都应该终止于抽象类或者接口。推出以下 ：任何变量都不应该持有一个指向具体类的指针或者引用；任何类都不应该从具体类派生；任何方法都不应该覆它的任何基类中已经实现了的方法。
什么是高层策略，它是应用背后的抽象，是哪些不随具体细节的改变而改变的真理。他是系统内部的系统-它是隐喻。

接口隔离原则（ISP）
不应该强迫客户依赖于它们不用的方法。
这个原则用来处理胖接口所具有的缺点，如果类的接口不是内聚的，就表示该类具有胖的接口。换句话说，类的胖接口可以分解成多组方法，每一组方法都服务于一组不同的客户程序。可做到函数间的拆分，以便以后更好地组合。