第七章 SRP：单一职责原则
任何一个软件模块都应该只对某一类行为者负责。软件模块指的是一组紧密相关的函数和数据结构。
问题：一个类的三个函数分别对应的是三类不同的行为者，违反了SRP设计原则。
实际上等于使三类行为者的行为耦合在了一起，这可能会导致CFO团队的命令影响到COO团队所依赖的功能。比如为了避免重复编码，而存在算法共享的情况，一个团队修改了算法，会对另一个团队产生影响。
因此SRP强调服务不同行为者的代码一定要被分开。
解决方案：
1.数据与函数分离
设计三个类共同使用一个不包括函数的、简单的数据类。每个类只包含与之相关的函数代码，互相不可见，这样就不存在互相依赖的情况了。缺点：需要在程序里处理三个类。
2.使用Facade设计模式
第八章 OCP：开闭原则
设计良好的计算机软件应该易于扩展，同时抗拒修改。
OCP是我们进行系统架构设计的主导原则，其主要目标是让系统易于扩展，同时限制其每次被修改所影响的范围。
实现方式是通过将系统划分为一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，使得高阶组件不会因低阶组件被修改而受到影响。
第九章 LSP：里式替换原则
里氏代换原则严格版定义：
如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。
里氏代换原则通俗版定义：
所有引用基类（父类）的地方必须能透明地使用其子类的对象。
里氏代换原则是实现开闭原则的重要方式之一。在传递参数、定义成员变量、定义局部变量、确定方法返回类型时都可使用里氏代换原则。针对基类编程，在程序运行时再确定具体子类。
第十章 ISP：接口隔离原则
1.客户端不应该依赖它不需要的接口。
2.类间的依赖关系应该建立在最小的接口上。
接口隔离原则是对接口的使用进行约束规范的一个原则，它告诉我们要想把接口用好，关键在于隔离。
接口隔离原则告诉我们，不要把一大堆方法塞进一个接口里，导致这个接口变得臃肿无比。应该要根据实际需要，让接口中只有用得上的方法，也就是说要细化我们的接口。
ISP在软件架构的使用：
任何层次的软件设计如果依赖于不需要的东西，都会是有害的。从源代码层次来说，这样的依赖关系会导致不必要的重新编译和重新部署，对更高层次的软件架构设计来说，问题也是类似的。
第十一章 DIP：依赖反转原则
如果想要设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型，而非具体实现。
编码守则：
1.应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。
对象的创建过程也应该受到严格限制，通常会选择用抽象工程设计模式。
2.不要在具体实现类上创建衍生类。
3.不要覆盖包含具体实现的函数。
4.应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事物的名字。