面向对象开发基本原则笔记-（理解记忆）

面向对象开发基本原则笔记-（理解记忆）

单一职责原则

修改一个类的原因只能有一个。
尽量让每个类只负责软件中的一个功能，并将该功能完全封装（你也可称之为隐藏）在该类中。

这条原则的主要目的是减少复杂度。

示例：===================================================================
我们有几个理由来对 雇员 Employee 类进行修改。第一个理由与该类的主要工作（管理雇员数据）有关。但还有另一个理由：时间表报告的格式可能会随着时间而改变，从而使你需要对类中的代码进行修改。
解决该问题的方法是将与打印时间表报告相关的行为移动到一个单独的类中。这个改变让你能将其他与报告相关的内容移动到一个新的类中。

开闭原则

对于扩展，类应该是“开放”的；对于修改，类则应是“封闭”的。
根据这条原则，一个类可以同时是“开放（对于扩展而言）”和“封闭（对于修改而言）”的。

本原则的主要理念是在实现新功能时能保持已有代码不变。

如果你可以对一个类进行扩展，可以创建它的子类并对其做任何事情（如新增方法或成员变量、重写基类行为等），那么它就是开放的。
有些编程语言允许你通过特殊关键字（例如 final ）来限制对于类的进一步扩展， 这样类就不再是“开放”的了。如果某个类已做好了充分的准备并可供其他类使用的话（即其接口已明确定义且以后不会修改），那么该类就是封闭（你可以称之为完整）的。

示例：===================================================================

你的电子商务程序中包含一个计算运输费用的 订单 Order类，该类中所有运输方法都以硬编码的方式实现。如果你需要添加一个新的运输方式，那就必须承担对 订单 类造成破坏的可能风险来对其进行修改。

可以通过应用策略模式来解决这个问题。首先将运输方法抽取到拥有同样接口的不同类中。

现在， 当需要实现一个新的运输方式时， 你可以通过扩展 运输方式Shipping接口来新建一个类， 无需修改任何 订单 类的代码。 当用户在 UI 中选择这种运输方式时，订单 类客户端代码会将订单链接到新类的运输方式对象。
此外，根据单一职责原则，这个解决方案能够让你将运输时间的计算代码移动到与其相关度更高的类中。

里式替换原则

当你扩展一个类时， 记住你应该要能在不修改客户端代码的情况下将子类的对象作为父类对象进行传递。
任何时候都可以用子类型替换掉父类型。

这意味着子类必须保持与父类行为的兼容。在重写一个方法时，你要对基类行为进行扩展，而不是将其完全替换。

1、子类方法的参数类型必须与其超类的参数类型相匹配或更加抽象。
假设某个类有个方法用于给猫咪喂食：feed(Cat c)。客户端代码总是会将“猫（cat）”对象传递给该方法。

• 好的方式：假如你创建了一个子类并重写了前面的方法，使其能够给任何“动物（animal，即‘猫’的超类）”喂食： feed(Animal c) 。如果现在你将一个子类对象而非超类对象传递给客户端代码，程序仍将正常工作。该方法可用于给任何动物喂食，因此它仍然可以用于给传递给客户端的任何“猫”喂食。
• 不好的方式： 你创建了另一个子类且限制喂食方法仅接 受 “孟 加 拉 猫 （BengalCat， 一 个 ‘猫’ 的 子 类）”：feed(BengalCat c) 。如果你用它来替代链接在某个对象中的原始类，客户端中会发生什么呢？由于该方法只能对特殊种类的猫进行喂食，因此无法为传递给客户端的普通猫提供服务，从而将破坏所有相关的功能。

2、子类方法的返回值类型必须与超类方法的返回值类型或是其子类别相匹配。
假如你的一个类中有一个方法 buyCat(): Cat 。 客户端代码执行该方法后的预期返回结果是任意类型的“猫”。

• 好的方式：子类将该方法重写为： buyCat(): BengalCat 。客户端将获得一只“孟加拉猫”，自然它也是一只“猫”，因此一切正常。
• 不好的方式： 子类将该方法重写为： buyCat(): Animal 。现在客户端代码将会出错，因为它获得的是自己未知的动物种类（短吻鳄？熊？），不适用于为一只“猫”而设计的结构。

3、子类中的方法不应抛出基础方法预期之外的异常类型。
换句话说，异常类型必须与基础方法能抛出的异常或是其子类别相匹配。这条规则源于一个事实：客户端代码的 try-catch代码块针对的是基础方法可能抛出的异常类型。因此，预期之外的异常可能会穿透客户端的防御代码，从而使整个应用崩溃。

4、子类不应该加强其前置条件。
例如，基类的方法有一个 int类型的参数。如果子类重写该方法时，要求传递给该方法的参数值必须为正数（如果该值为负则抛出异常），这就是加强了前置条件。客户端代码之前将负数传递给该方法时程序能够正常运行，但现在使用子类的对象时会使程序出错。

5、子类不能削弱其后置条件。
假如你的某个类中有个方法需要使用数据库，该方法应该在接收到返回值后关闭所有活跃的
数据库连接。你创建了一个子类并对其进行了修改，使得数据库保持连接以便重用。但客户端可能对你的意图一无所知。由于它认为该方法会关闭所有的连接，因此可能会在调用该方法后就马上关闭程序，使得无用的数据库连接对系统造成“污染”。

6、超类的不变量必须保留。
这很可能是所有规则中最不“形式”的一条。不变量是让对象有意义的条件。例如，猫的不变量是有四条腿、一条尾巴和能够喵喵叫等。不变量让人疑惑的地方在于它们既可通过接口契约或方法内的一组断言来明确定义，又可暗含在特定的单元测试和客户代码预期中。

7、子类不能修改超类中私有成员变量的值。

示例（反例）：==============================================================

只读文件 ReadOnlyDocuments 子类中的 save 保存 方法会在被调用时抛出一个异常。基础方法则没有这个限制。这意味着如果我们没有在保存前检查文档类型，客户端代码将会出错。
代码也将违反开闭原则，因为客户端代码将依赖于具体的文档类。如果你引入了新的文档子类，则需要修改客户端代码才能对其进行支持。

可以通过重新设计类层次结构来解决这个问题：一个子类必须扩展其超类的行为，因此只读文档变成了层次结构中的基类。可写文件现在变成了子类，对基类进行扩展并添加了保存行为。

接口隔离原则

客户端不应被强迫依赖于其不使用的方法。
尽量缩小接口的范围，使得客户端的类不必实现其不需要的行为。

示例：===================================================================

假如你创建了一个程序库，它能让程序方便地与多种云计算供应商进行整合。尽管最初版本仅支持阿里云服务，但它也覆盖了一套完整的云服务和功能。
假设所有云服务供应商都与阿里云一样提供相同种类的功能。但当你着手为其他供应商提供支持时，程序库中绝大部分的接口会显得过于宽泛。其他云服务供应商没有提供部分方法所描述的功能。

尽管你仍然可以去实现这些方法并放入一些桩代码，但这绝不是优良的解决方案。更好的方法是将接口拆分为多个部分。能够实现原始接口的类现在只需改为实现多个精细的接口即可。其他类则可仅实现对自己有意义的接口。

与其他原则一样，你可能会过度使用这条原则。不要进一步划分已经非常具体的接口。记住，创建的接口越多，代码就越复杂。因此要保持平衡。

依赖倒置原则

高层次的类不应该依赖于低层次的类。 两者都应该依赖于抽象接口。抽象接口不应依赖于具体实现。具体实现应该依赖于抽象接口。

• 低层次的类实现基础操作（例如磁盘操作、传输网络数据和连接数据库等）。
• 高层次类包含复杂业务逻辑以指导低层次类执行特定操作。

依赖倒置原则通常和开闭原则共同发挥作用：你无需修改已有类就能用不同的业务逻辑类扩展低层次的类。

示例：===================================================================

在本例中，高层次的预算报告类（BudgetReport）使用低层次的数据库类（MySQLDatabase）来读取和保存其数据。这意味着低层次类中的任何改变（例如当数据库服务器发布新版本时）都可能会影响到高层次的类，但高层次的类不应关注数据存储的细节。

要解决这个问题，你可以创建一个描述读写操作的高层接口，并让报告类使用该接口代替低层次的类。然后你可以修改或扩展低层次的原始类来实现业务逻辑声明的读写接口。

其结果是原始的依赖关系被倒置：现在低层次的类依赖于高层次的抽象。

【参考资料】书籍：深入设计模式