理论指导实践，同时实践是检验真理的唯一标准。在设计模式当中，原则就是其中的理论，而具体的设计模式就是在原理上面的实践。到现在为止，设计模式一共有23种，每个设计模式都是遵照一定的原则进行设计的。
我们常讲，面向对象具有三大特性，继承、封装、多态；我们设计软件的时候要到高内聚，低耦合；我们设计接口的时候要通用，有扩展性。其实，设计模式的原则，就是体现在我们的这些理念当中。但是，对于大多数人来讲，他们只是知道有这样的一个理念，却在实际的编码过程中，把业务逻辑写在jsp页面上，而且还写了1k行、重复的代码，一遍又一遍地复制，黏贴、方法里面的入参有十几二十个等等。所以，当讲到高内聚，低耦合的时候，不仅仅是认识这几个字，还需要知道的是这几个字背后的含义，并且能在实际当中得到应用，因为我们做的并不是口头上的编码，或者ppt编码，而是实际上要在ide上敲的。
啰嗦了那么多，那到底设计模式当中有哪些原则呢？下面就是他们的原则及其具体的含义，原则和含义是摘取至《设计模式从入门到精通-杨帆-电子工业出版社》或者维基百科，而通俗理解是我个人的理解，会比较白话文一点
| 原则 | 含义 | 通俗理解 |
|---|---|---|
| 单一功能原则(Single responsibility principle，SRP) | 每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来 | 一个类只实现一个功能，不该管的不要管 |
| 开闭原则(Open-Closed Principle, OCP) | 软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的 | 原来的代码不要去改，要加新的功能或者修改原来的功能的时候，采用添加方法的方式进行修改 |
| 里氏代换原则(Liskov Substitution Principle, LSP) | 若对每个类S的对象O1，都存在一个类T的对象O2，使得在所有针对T编写的程序P中，用O1替换O2后，程序P行为功能不变，则S是T的子类 | 本来被调用传入的是父类，替换传入子类以后，程序不会发生任何的变化 |
| 依赖倒转原则(Dependence Inversion Principle, DIP) | 高层模块不应该依赖底层模块，两者都应该依赖抽象。抽象不应该依赖希捷，细节应该依赖于抽象 | 面向接口编程，调用其他模块的时候调用接口，而不是具体的实现类 |
| 接口隔离原则(Interface Segregation Principle, ISP) | 不要强迫客户依赖于它们不需要的方法，应用接口将两者隔离 | 在接口设计中，尽可能小，尽可能细化，调用方需要的接口才提供，不要提供一堆别人不需要的接口 |
| 合成复用原则(Composite Reuse Principle, CRP) | 复合优先于继承 | 在A类中引入B类，当做A类的成员变量，而不是在使用B类extends A类 |
| 迪米特法则(Law of Demeter, LoD) | 每个单元只能和它的朋友交谈：不能和陌生单元交谈 | A类调用B类的方法，B类就提供必要的一些方法就可以了，自己内部的一些方法尽可能不要让A类知道 |
这些就是我们设计模式当中的原则，七个，不多不少，所有的系统的软件设计的根基也就是基于这七个原则，虽然现在还没有提出他的实践——设计模式，但是根据这七个原则，我们也可以写出像样子的代码来。例如根据单一功能原则和接口隔离原则，最极端的就是我们一个接口中就只有一个方法。根据迪米特法则，我们可以一开始把所有的方法都写成private的，其他类需要调用的时候，才根据defalut-->protected-->public的范围去进行修改。当然，我们不可能采用这么极端的方式去写代码。软件工程是一个平衡的工程，任何的设计会有好处也有不利的地方，考虑到开发成本，开发周期，我们的代码并不会完全按照规范来开发，会进行适量的冗余，这是权衡规范和实际的情况来定的。
接下来，对每一个原则，都会有一篇文章，具体探讨这个原则的细节内容，也会给出例子，包括代码的例子以及生活当中的例子，尽可能把所有找到的资料进行归纳总结。
