1.开闭原则（开闭原则OCP）
对扩展开放，对修改关闭。
就像实现一个计算器一样，实现了简单的加减乘除之后，如果要加一些其他的运算，比如开根，比如求次方运算，这时候就不能对原来的代码进行修改，我们可以写一个基类Opreation，自带getCalValue（int opeA，int opeB）方法，所有加减乘除等操作都是这个类派生出来的操作类AddOperation，SubOperation，我们只要切换运算符号，就可以new一个相应的类出来，然后只要传进去两个操作数，我们就可以得到最后的结果，这样子就可以实现对扩展开放，对修改关闭。
2.里氏替换原则（Liskov Substitution Principle LSP）
子类必须能够替换基类，否则不应当设计为其子类。也就是说，子类只能去扩展基类，而不是隐藏或者覆盖基类。
就比如上面提到的计算器设计，我们就可以用派生出来的AddOperation，子操作类分别完成对操作数的加和减操作。
3.依赖倒置原则（依赖倒置原则DIP）
依赖于抽象而不依赖于具体。
说白了，就是针对接口编程，不要针对实现编程。
无论主板，CPU，内存，硬盘都是针对接口设计了，只要接口是稳定的，那么任何一个模块坏了都不会影响到其他的模块，说白了，主板不依赖于内存，内存也不依赖于主板，也就是高层模块和底层模块都没有互相依赖，他们依赖的都是接口。
4.接口隔离原则（接口隔离原理ISP）
第一种定义: 客户端不应该依赖它不需用的接口。
ISP可以达到不强迫客户（接口的使用方）依赖于他们不用的方法，接口的实现类应该只呈现为单一职责的角色（遵守SRP原则）。
ISP还可以降低客户之间的相互影响——当某个客户程序要求提供新的职责（需求变化）而迫使接口发生改变时，影响到其他客户程序的可能性会最小。
第二种定义：类间的依赖关系应该建立在最小的接口上。
比如在应用继承时，由于子类将继承父类中的所有可用的方法；而父类中的某些方法，在子类中可能并不需要。例如，普通员工和经理都继承自雇员这个接口，员工需要每天写工作日志，而经理则不需要。因此不能用工作日志来卡经理，也就是经理不应该依赖于提交工作日志这个方法。
ISP强调的是接口对客户端的承诺越少越好，并且要做到专一。当某个客户程序的要求发生变化，而迫使接口发生改变时，影响到其他客户程序的可能性小。这实际上就是接口污染的问题。
5.单一职责原则（组成/聚合重用原则CARP）
就一个类而言，应该仅有一个引起它变化的原因。
比如手机，可能单一做好它的通话功能就非常棒了，它多一个摄像功能，而且如果做的还比较鸡肋的话，到用到摄像的时候，还不好使，修的话，你又要去拆一整个手机，去排查它坏在哪了，这就很尴尬了。
软件设计真正要做的许多内容，就是发现职责并把那些职责互相分离。如果你能够想到多余一个的动机去改变一个类，那么这个类就具有多于一个的职责。
单一职责原则和接口隔离原则的区别，其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。
6.迪米特原则或者最少知识原则（得墨忒耳定律或最小知识原理LOD或LKP）
根本思想是强调了类之间的松耦合。
在类的结构设计上，每一个类都应当尽量降低成员的访问权限。
类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。
比如说公司部门之间协作，你不需要知道要找这个部门的具体谁帮你做，你只需要知道找这个部门的主管是谁就好了，他会帮你安排人。