单一职责原则

对于一个类甚至小到一个方法都应该尽可能的职责单一，明确。这么做的好处是提高项目的可维护性，举个例子来说：假如A方法有两个职责R1，R2；那么这两个职责中任何一个发生变化的时候，都需要修改方法A，那么当R1变化时，修改方法A，有可能就会影响到R2。所以在代码设计时，尽可能的让每一个类，每一个方法的职责明确！尽量不要出现一套代码完成两种职责的事情。

依赖倒置原则

高层模块不应该依赖低层模块，二者都应该依赖其抽象，翻译一下就是面向接口编程；接口一般是行为的集合，也就是尽可能的对行为抽象。

抽象不应该依赖细节，细节应该依赖抽象。

里氏替换原则

只要父类出现的地方，都可以用子类替换，并且不会对程序造成影响，在实现上来说就是子类不要覆盖父类的非抽象方法，但可以重载。

重载时需要注意，入参的要求要比父类宽松（保证可以进入），返回要比父类更加严格（保证出去不会有问题），这也正是实现里氏替换的基础。

接口隔离原则

翻译一下就是接口的功能尽可能单一，接口本质上是两个类之间关系的纽带，关系中不需要有的，在接口中不应该体现。如：A 通过接口I依赖B，假如接口I中有A 不需要的方法，那么这个接口就是不合理的，B必须要实现这个不需要的方法，徒劳无功。

迪米特法则（最少知道原则）

也就是说一个对象要对其他对象保持尽可能少的了解，即低耦合性，低耦合可以最大限度的保证代码的可复用性。这个实际上是针对被依赖的类来说的，对于被依赖的类，尽可能的将复杂的逻辑封装起来，对外只提供public方法，外部不需要知道内部的逻辑。

开闭原则

尽量通过扩展来面对需求的更改或者系统的变化，尽量不要对原有内容修改。