面向对象的设计原则（一）

以下是读敏捷软件开发 原则，模式与实践

做的读书笔记。

1.单一职责原则（SRP）

内聚性：一个模块的组成元素之间的功能相关性

就一个类而言，应该仅有一个引起它变化的原因。

如果一个类承担的职责过多，就等于把这些这种耦合在一起。一个职责的变化可能会削弱或者抑制这个类其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。

什么是职责

职责：变化的原因，如果你能够想到多于1个的动机去改变一个类，那么这个类就具有多于一个的职责。

变化的轴线仅当变化实际发生时才有真正的意义，如果没有征兆，那么去应用SRP或者任何其他原则都是不明智的。

常见违反SRP：业务规则和对于持久化的控制混合一起（因为业务规则经常变化，而持久化不会）

测试驱动开发实践常常会远在设计出现臭味以前就迫使我们分离这两个职责，如果测试不能迫使我们分离职责的话，僵化性和脆弱性臭味就会很强烈，我们可以使用FACADE或者PROXY模式进行重构吗，分离职责。

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

2.开放-封闭原则（OCP）

软件实体（类，模块，函数等）应该是可以扩展的，但是不可修改的

如果程序中一处改动就会产生连锁反应，导致一系列相关模块的改动，设计就具有僵化性臭味。OCP建议我们重构，那么以后再进行同样的改动时，就只需添加新的代码，而不必改动已经正常运行的代码。

描述：

遵循OCP模块主要特征

     1.对于扩展是开发的：模块的行为是可以扩展的，当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为，即我们可以改变模块的功能

     2.对于更改是封闭的：对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。

1.实现

关键是抽象。模块可以操作一个抽象体，由于模块依赖于一个固定的抽象体，所以它对于更改可以是关闭的，同时，通过从这个抽象体派生来扩展此模块行为（面向接口编程）

预测变化和贴切的结构

无论模块是多么的封闭，都会存在一些无法对之封闭的变化，即设计人员必须对于他的设计的模块对哪种变化封闭做出选择，他必须先猜测出最有可能变化的变化种类，然后构造抽象来隔离那些变化。

方法：进行适当的调查，提出正确的问题，并且使用我们的经验和一般常识，最终，我们会一直等到变化发生时才采取行动。

2.怎样隔离变化：

不要使用放置吊钩方式，因为放置的吊钩常常是错误的，且要去坚持和维护她们

     1.只受一次愚弄

     我们编写最初代码时，假设变化不会发生，当变化发生时，我们就创建抽象来隔离以后发生的同类变化。

     2.刺激变化

          1.测试驱动开发。先编写测试，我们迫使系统成为可测试的。在一个可测试性的系统中发生变化，可以坦然应对，因为我们已经构建了使系统可测试的抽象。并且通常这些抽象中许多都会隔离以后发生的其他种类的变化。

          2.短迭代周期开发---一个周期是几天而不是几周。

          3.我们在加入基础结构前就开发特性，并经常把特性展示给涉众。

          4.我们首先开发最重要的特性

          5.尽早地，经常性发布软件，尽可能快地，尽可能频繁地把软件展示给客户和使用人员。

     3.使用抽象获得显式封闭

     封闭式建立在抽象基础上的。

     4.使用“数据驱动”的方法获取封闭性

3.结论

OCP都是面向对象设计的核心所在。遵循这个原则可以带来好处（灵活性，可重用性，可维护性）。然而，并不是说只要使用一种面向对象语言就遵循这个原则，正确做法是应该仅仅对程序中呈现出频繁变化的那些部分作出抽象。拒绝不成熟的抽象和抽象本身一样重要。