本节对4个基本原则及1个基本法则进行简要整理介绍。
拍摄UFO——单一职责原则
单一职责：就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
随着移动终端的发展，智能手机已经集成了众多功能：听音乐、玩游戏、拍照、摄像等。但有时一件产品简单一些，职责单一些，或许是更好的选择，比如摄像机拍摄性能要比手机更好一些。
比如要写一个WinForm窗口程序，总不能把操作的方法都写入窗口类，更好的策略应该是将界面代码和逻辑代码相分离，即将界面职责和逻辑职责单独分开。
（手机的发展有它的特点，而编程时，我们却是要在类的职责分离上多思考，做到单一职责，这样代码才是真正的易维护、易扩展、易复用、灵活多样）
考研求职两不误——开闭原则
开闭原则：对于扩展是开放的，对于更改是封闭的。
面对需求的改变应保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本。当然改变大都是不可预测的，设计人员需要先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。
比如在简单工厂运算器问题中，如果想添加一个乘法运算，只需要新增一个运算子类就行，与加法、减法、客户端隔离开来。这样就是面对需求，对程序的改动是通过增加新代码实现，而不是更改现有的代码。
（比如，考研过程中，考研本身是不会改变的，为了做完全准备，可以在考研期间不影响考研本身前提下，扩展的写一写简历了解招聘的资讯）
会修电脑不会修收音机——依赖倒转原则
依赖倒转原则：
- 高层模块不应依赖低层模块，两个都应依赖抽象
- 抽象不应依赖细节，细节应该依赖抽象
我们可以把电脑理解成大的软件系统，任何部件如CPU、内存、硬盘、显卡等都可以理解为程序中封装的类或程序集，不管哪一个出了问题都可以在不影响别的部件的前提下进行修改和替换。具体一点就是接口和抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其它受到影响。这使得高层模块和低层模块都能很好被复用。
收音机就是典型的耦合过度，只要收音机出问题，不懂的人根本没法修，因为任何问题都可能涉及其他部件，各个部件相互依赖，难以维护。
不太理解的话在看下面一个例子：
从上面的类图中可以看出，司机类和奔驰车类都属于细节，并没有实现或继承抽象，它们是对象级别的耦合。通过类图可以看出司机有一个drive()方法，用来开车，奔驰车有一个run()方法，用来表示车辆运行，并且奔驰车类依赖于司机类，用户模块表示高层模块，负责调用司机类和奔驰车类。
这样乍一看没问题，但是有一天如果司机想换一辆宝马了，但是却不能开，因为司机类里没有对宝马的依赖。下面引入依赖倒转原则重新设计一下类图：
可以看出在新增低层模块（汽车）时，只修改了高层模块（Client），对已有的司机和车类都不用变动。
里氏代换原则
里氏代换原则：子类型必须能够替换掉父类型。
迪米特法则
迪米特法则：如果两个类不直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。
（类似于在controller层调用service层，再通过service层调用dao层访问数据库一样；而不是直接的由控制层调用数据访问层。）
