单一职责原则(SRP : Single Response Principle)
就一个类而言,应该仅有一个引起它变化的原因。
在这里,职责的定义是: “变化的原因”。
对于何时遵循 SRP 有以下的考虑:
1.如果应用程序的变化会影响到类中某一种职责,那么就应该将它与另一种职责分开,这
样做可以避免客户应用程序和类中的这两职责耦合在一起。
2.如果应用程序的变化总是会导致两个职责同时变化,那么就不必要分离它们。实际上,
分离它们会引起不必要的复杂性。
从上可以得知:变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆,那么
去应用 SRP,或者任何其它原则都是不明智。
实际应用:持久化(Persistence)
实际开发中,考虑到业务规则是会频繁改变的,而持久化的方式却不会如此频繁的变化,
并且变化的原因也是完全不同的。如果把业务规则和持久化方式绑定到一起,就会为以后
的开发、维护造成麻烦。运用分层(layer)架构模式或者 TDD 开发方式可以很早分离这两
个职责,特殊情况下,还可以使用 FACADE 或者 PROXY 模式对设计进行重构,分离这两
个职责。
开闭原则(OCP : The Open-Close Principle)
描述:软件实体(类、模型、函数等等)应该是可以扩展的,但是不可修改。
遵循开闭原则设计出的模块具有两个主要的特征。它们是:
1. “对于扩展是开放的”(Open for extension)。
这意味着模块的行为是可以扩展的。当应用的需要改变时,我们可以对模块进行扩展,
使其具有满足那些改变的新行为。换句话说,我们可以改变模块的功能。
2. “对于更改是封闭的”(Closed for modification)。
对模块行为进行扩展时,不必改动模块的源代码或者二进制代码。模块的二进制可执行
版本,无论是可链接的库、DLL 或者 Java 的.jar 文件,都无需改动。
对于 OCP,关键的是 抽象
模块可以操作一个抽象体。由于模块依赖于一个固定的抽象体,所以它对于更改可以是关
闭的。同时,通过从这个抽象体派生,也可以扩展此模块的行为。
在许多方面,OCP 都是面向对象设计的核心所在。但实际应用中,滥用 OCP 原则也是错误
的。正确的做法是应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的
抽象和抽象本身一样重要。