《敏捷软件开发》读书笔记 （2） -- 设计原则

 

1. SRP，单一职责原则：就一个类而言，应该仅有一个引起它变化的原因

·        将过多的职责耦合在一个类中导致了脆弱设计

·        职责是变化的原因

·        如果应用程序变化的方式总是导致两个职责同时变化，则不应该分离他们

·        把业务规则和持久化子系统绑定在一起是自讨苦吃，这违反了单一职责原则。可以使用 Facade 或者 Proxy 模式进行重构，以解除这种耦合

·        软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离

2. OCP，开放封闭原则：软件实体（类、模块、函数等等）应该是可扩展的，但是不可修改的<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

·        任何系统在其生命周期内都回变化

·        变化应该是导致添加新的代码，而不是修改已经正常运行的代码

·        OCP的关键是抽象

·        接口和客户的关系要比实现它的类和客户的关系更密切

·        策略模式和模板模式是用以满足OCP的最常用方法

·        没有对于所有情况都贴切的模型，也即不可能完全封闭，所以应该预先猜测出最有可能的变化种类

·        拒绝不成熟的抽象和抽象本身一样重要

 

3. LSP，LISKOV可替换原则：子类型必须能够替换它们的基类型

·        对于LSP的违反也潜在的违反了OCP

·        正方形从长方形继承的例子微妙的违反了这种原则

·        在考虑一个特定的设计是否恰当时，不能孤立地来看这个解决方案，必须根据设计的使用者所做出的合理假设来审视它

·        对象的行为方式是软件真正所关注的问题， IS A 关系是就行为而言的

·        派生类只能使用相等或更弱的前置条件来替换原始的前置条件，只能使用相等或更强的前置条件来替换原始的后置条件。

·        完成的功能少于基类的派生类通常不能替换基类，也不符合LSP

·        派生类不应该抛出基类不能预计的异常，否则违反LSP

4. DIP，依赖倒置原则：高层模块不应该依赖于底层模块，二者都应该依赖于抽象

·        抽象不应该依赖于细节，细节应该依赖于抽象

·        所有结构良好的面向对象架构都具有清晰的层次定义，每个层次通过一个定义良好的受控接口向外提供一组内聚的服务

·        一个对象持有另外一个具体对象的引用可能破坏了DIP

·        策略不应该依赖于细节，细节和策略都应该依赖于抽象

·        如果依赖关系是倒置的，那么就是面向对象的设计，否则就是过程化的设计。

5. ISP，接口隔离原则：不应该强迫客户依赖于他们不用的方法，将不同的接口分离，而不是集合

·        如果强迫客户程序依赖于那些他们不使用的方法，那么这些客户程序就面临着由于这些未使用方法的改变而带来的变更。

·        使用委托分离接口

·        使用多重集成分离接口