3.4 单一职责原则

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

　　　　如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。

　　这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。

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

　　　　其实要去判断是否应该分离出类来并不难：如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

　　　　在编程时，我们要在类的职责分离上多思考，做到单一职责，这样你的代码才是真正的易维护、易扩展、易复用、灵活多样。

4.2 开放-封闭原则

　　　　开放-封闭原则：软件实体（类、模块、函数等）应该可以扩展，但是不可修改。

　　　　这个原则有两个特征：

　　　　　　　第一：对于扩展是开放的，

　　　　　　　第二：对于更改是封闭的。

　　　　在软件设计模式中，这种不能修改但可以扩展的思想也是最重要的一种设计原则。

　　　　我们在做任何系统的时候，都不要指望系统一开始时需求就确定再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，

　　那么如何设计能让软件既容易维护又不容易出问题呢？ 最好的办法就是多扩展，少修改。

　　　　开放-封闭原则的意思就是说：在设计的时候，要时刻考虑，尽量让这个类是足够好的，写好了就不用再修改了，如果有新需求来，我们增加一些类就完事了，

　　原来的代码能不动则不动。

　　　　当然，绝对的对修改的关闭是不可能的。无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该

　　对哪种变化封闭做出选择。它必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。

　　　　小菜：“那还是需要猜测程序可能会发生的变化，猜对了，那是成功，猜错了，那就完全走到另一面去了，把本该简单的设计做得非常复杂，很不划算呀。而且事先猜测，这又是很难做到的。”

　　　　大鸟：“你说的没错，我们是很难预先猜测，但我们却可以在发生小变化时，就及早去想办法应对发生更大变化的可能。也就是说，等到变化发生时立即采取行动。”

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

　　　　比如，我之前让你写的加法程序，你很快在一个client类中就完成了，此时变化还没有发生。然后我让你加一个减法功能，你发现，增加功能需要修改原来这个类，这就违背了今天讲到的“开放-封闭原则”，

　　于是你就该考虑重构程序，增加一个抽象的运算类，通过一些面向对象的手段，如继承、多态等来隔离具体加法、减法与 client 耦合，需求依然可以满足，还能应对变化。这时我又要你再加乘除法功能，你就

　　不需要再去更改 client 以及加法减法的类了，而是增加乘法和除法子类就可。 即，面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。这就是“开放-封闭原则”的精神所在。

　　　　当然，并不是什么时候应对变化都是容易的。我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。

　　　　开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分

　　做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

　　举个例子：

　　　　其实，迟到不是主要问题，每天保证 8 小时的工作量是老板最需要的，甚至 8 小时工作时间也不是主要问题，业绩目标的完成或超额完成才是最重要的指标，

　　所以应该改变管理方式，比如弹性上班工作制，早到早下班，晚到晚下班，或者每人每月允许三次迟到，迟到者当天下班补时间等等。对市场销售人员来说可能就

　　更加以业绩为标准了，工作时间不固定了 —— 这其实就是对工作时间或业绩成效的修改关闭，而对时间制度扩展的开放。

　　　　这就需要老板自己很清楚最希望达到的目的是什么，指定的制度才最合理有效。

5.3 依赖倒转原则

　　　　可以把 PC 电脑理解成是大的软件系统，任何部件如 CPU、内存、硬盘、显卡等都可以理解为程序中封装的类或程序集，由于 PC 易插拔的方式，那么不管哪一个出问题，都可以在不影响别的部分的前提下进行修改或替换。

　　　　PC 电脑里叫易插拔，面向对象里把这种关系叫做 “强内聚、松耦合”。

　　　　CPU 只需要把接口定义好，内部再复杂我也不让外界知道，而主板只需要预留与 CPU 针脚的插槽就可以了。这就是接口的好处。

　　　　PC 的接口是有限的，所以扩展有限，软件系统设计得好，却可以无限地扩展。

　　　　依赖倒转原则：抽象不应该依赖细节，细节应该依赖于抽象。说白了，就是要针对接口编程，不要对实现编程。

　　　　依赖倒转原则：

　　　　　　　　高层模块不应该依赖低层模块。两个都应该依赖抽象。（都应该依赖于接口）

　　　　　　　　抽象不应该依赖细节，细节应该依赖抽象。

　　为什么要叫倒转呢？

　　　　在面向对象的开发中，为了使得常用代码可以复用，一般都会把这些常用代码写成许许多多函数的程序库，这样我们在做新项目时，直接调用这些低层的函数就可以了。比如大多数项目都要访问数据库，所以我们可以把访问数据库的代码写成函数，

　　每次做新项目时就去调用这些函数，这也就叫做高层模块依赖低层模块（依赖倒转原则中提到，高层模块不应该依赖低层模块）。

　　　　但问题是我们要做新项目时发现，业务逻辑的高层模块都是一样的，但客户却希望使用不同的数据库或其它的信息存储方式（低层模块），这时就出现麻烦了。我们希望能再次利用这些高层模块，但高层模块都是与低层的数据库访问绑定在一起的，

　　没办法复用这些高层模块，这就非常糟糕了。

　　　　而如果不管高层模块还是低层模块，它们都依赖于抽象（也就是说接口或抽象类），只要接口是稳定的，那么任何一个更改都不用担心其他受到影响，这就使得无论高层模块还是低层模块都可以很容易地被复用。这才是最好的办法。

　　　　依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编写程序，即程序中所有的依赖关系都是终止于抽象类或者接口，那

      就是面向对象的设计，反之那就是过程化的设计了。

5.4 里氏代换原则

　　　　里氏代换原则：子类型必须能够替换掉它们的父类型。

　　　　它的白话翻译是：一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。

　　　　只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。

　　　　正是由于子类型的可替代性才使得使用父类类型的模块在无须修改的情况下就可以扩展。（子类继承父类，新的模块继承使用父类的模块？）

　　　　【完】