1、开闭原则

开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。可以提高软件系统的可复用性及可维护性。开
闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统，例如：我们版本更新，我尽可能不修改源代码，但是可以增加新功能。

说白了就是，如果我们要增加新功能，不要影响到原有的功能。原来的类保持不变，然后弄一个新的类去extends原来的类，新的类再去写新的逻辑。对旧功能关闭，对新的功能进行扩展。

2.依赖倒置原则

依赖倒置原则（Dependence Inversion Principle,DIP）是指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节；细节应该依赖抽象。通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并能够降低修改程序所造成的风险。

依赖一个类的时候，最好依赖其接口，而不是依赖其具体的实现类，依赖接口有一个好处，如果对应的实现类增加了功能，则我们只需要在调用处调用新的方法即可。而接口和实现类增加对应的方法。

接下来看一个案例，还是以课程为例，先来创建一个类 Tom：

来调用一下：

Tom 热爱学习，目前正在学习 Java 课程和 Python 课程。大家都知道，学习也是会上瘾的。随着学习兴趣的暴涨，现在 Tom 还想学习 AI 人工智能的课程。这个时候，业务扩展，我们的代码要从底层到高层（调用层）一次修改代码。在 Tom 类中增加studyAICourse()的方法，在高层也要追加调用。如此一来，系统发布以后，实际上是非常不稳定的，在修改代码的同时也会带来意想不到的风险。接下来我们优化代码，创建一个课程的抽象 ICourse 接口：

然后写 JavaCourse 类：

再实现 PythonCourse 类：

修改 Tom 类：

来看调用：

我们这时候再看来代码，Tom 的兴趣无论怎么暴涨，对于新的课程，我只需要新建一个类，通过传参的方式告诉 Tom，而不需要修改底层代码。实际上这是一种大家非常熟悉的方式，叫依赖注入。注入的方式还有构造器方式和 setter 方式。我们来看构造器注入方式：

看调用代码：

根据构造器方式注入，在调用时，每次都要创建实例。那么，如果 Tom 是全局单例，则我们就只能选择用 Setter 方式来注入，继续修改 Tom 类的代码：

看调用代码：

现在我们再来看最终的类图：

切记：以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此大家在拿到需求之后，要面向接口编程，先顶层再细节来设计代码结构。

3、单一职责原则

一个类Or接口，只负责一个功能。

我们进行拆分

4、接口隔离原则

接口隔离原则（Interface Segregation Principle, ISP）是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。这个原则指导我们在设计接口时应当注意一下几点：
1、一个类对一类的依赖应该建立在最小的接口之上。
2、建立单一接口，不要建立庞大臃肿的接口。
3、尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。
接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括以后有可能发生变更的地方还要做一些预判。所以，对于抽象，对业务模型的理解是非常重要的。

就是说，一个接口尽量只设计对应的功能，不要跨功能。

下面我们来看一段代码，写一个动物行为的抽象：

从上面能看出来，Dog没有fly功能，所以只能空着，这样就违背了接口隔离原则。

5、迪米特法则

该让你看到的，就让你看到，不该的一律封闭。

迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle,LKP），尽量降低类与类之间的耦合。迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类，而出现在方法体内部的类不属于朋友类。

现在来设计一个权限系统，Boss 需要查看目前发布到线上的课程数量。这时候，Boss要找到 TeamLeader 去进行统计，TeamLeader 再把统计结果告诉 Boss。接下来我们还是来看代码：

Course 类：