软件设计原则-SOLID原则
笔记的大部分内容参考《架构整洁之道》。
SOLID原则的主要作用就是告诉我们如何将数据和函数组织成为类，以及如何将这些类链接起来称为程序。
一般情况下，软件构建中层结构的主要目标如下：
- 使软件可容忍被改动。
- 使软件更容易被理解。
- 构建可在多个软件系统中复用的组件。
SOLID原则的内容主要为如下。
SRP：单一职责原则
SRP原则全称为Single responsibility principle，但这并不是指每个模块都应该只做一件事。而是任何一个软件模块都应该只对一类行为者负责。
反面案例：重复的假象
某个工资管理系统中的Employee类有三个函数calculatePay()、reportHours()和save()。
这个类的三个函数分别对应的是三类非常不同的行为者，违反了SRP设计原则。
calculatePay()函数由财务部门制定，负责向CFO汇报。reportHours()函数由人力资源部门制定并使用，负责向COO汇报。save()函数是由DBA制定的，负责向CTO汇报。
这三个函数被放在了同一个类中，实际上就等于使这三类行为者的行为耦合在了一起，这有可能会导致CFO团队的命令影响到COO团队所依赖的功能。
例如（这里才是最主要的），calculatePay()函数和reportHours()函数使用了同样的逻辑来计算正常工作使用，二者都调用了另一个regularHours()函数。
如果CFO团队需要修改正常工作时数的计算方法，而COO团队不需要，如果在CFO团队的程序员没有注意到regularHours()函数同时被reportHours()调用了而直接对函数的逻辑进行修改的话，修改就会影响到COO团队的代码，但是他们却不知道代码被改了。
这样的案例还有很多，他们都有一个共同点：多人为了不同的目的修改了同一份源代码，这就很容易造成问题的产生。
为了避免这种问题，需要将服务不同行为者的代码进行切分。
解决方案
最简单直接的方法就是将数据与函数分离，设计三个类共同使用一个不包括函数的、十分简单的EmployeeData类，每个类只包含与之相关的函数代码，互相不可见，这样就不存在互相依赖的情况了。
这种方法的坏处在于：程序员要在程序里处理三个类，另一种解决办法是使用Facade设计模式
外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。降低访问复杂系统的内部子系统时的复杂度，简化客户端之间的接口。
样例：去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便。
当然也有些程序员更倾向于把最重要的业务逻辑与数据放在一起，那么我们也可以选择将最重要的函数保留在Employee类中，同时用这个类调用其他没那么重要的函数。（大概就是没那么重要就不要写在一起，单独开一个然后引用（其实感觉还是会导致上面反面案例的情况））
总而言之，上面的每一个类都分别容纳了一组作用于相同作用域的函数，而在该作用域之外，它们各自的私有函数是互相不可见的。
UML（Unified Modeling Language）统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。UML的定义包括UML语义和UML表示法两个元素。
UML图就是类似上面的这种样子的图，常用的有用例图、类图等。
在菜鸟教程的设计模式简介中，设计模式的六大原则是不包括SRP原则的，所以之后还要看看其他的设计模式。