1.单一职责原则
定义：就一个类而言，应该仅有一个引起它变化的原因。这句话的意思是说：我们不要让一个类承担过多的职责，如果一个类承担的职责过多，就等于把这些职责全部耦合子一起。一个职责的变化可能会削弱活着抑制这个类完成其他的职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到破环。比如我经常看到一些android开发在Activity中写网络数据处理逻辑，如果有listview列表的话也写在activity类中，问他们为什么这样写除了好找代码也没啥理由了，如果把它们拆分大别的类中不是更好找，更清晰了吗。如果acticity过于臃肿行数过多，显然不是什么好事，如果列表adpater和网络数据有变化，我们都要在这个activity来修改，就会导致这个activity的变化的原因太多，我们在版本维护的时候也会比较头疼。也就严重违背了定义“就一个类而言。应该仅有一个引起它变化的原因”。
2.开放封闭原则
定义：类、模块、函数等等等应该是可以拓展的，但是不可修改，开放封闭有两个含义，一个对于拓展是开放的，一个对于修改是封闭的。对于开发来说需求肯定是要变化的，但是新需求一来，我们就要把类重新改一遍这显然是令人头疼的，所以我们设计程序时面对需求的改变要尽可能的保证相对的稳定，尽量用新代码实现拓展来修改需求，而不是通过修改原来的代码来实现。假设我们要实现一个列表，一开始只有查询的功能，这时产品需要增加添加功能，过几天又要新增删除功能，大多人都是写一个方法通过传入不同的值来控制方法实现不同的功能，但是如果又要新增功能我们还的修改我们的方法。用开发封闭原则解决就是增加一个抽象的功能类，让增加和删除和查询作为这个抽象类的字类，这样如果我们在添加功能，你就会发现我们不需要修改原有的类，只需要添加一个功能类的字类实现功能类的方法就可以了。
3.里氏替换原则
定义：所有引用基类（父类）的地方必须能透明的使用其子类的对象，里氏替换原则告诉我们，在软件中将一个基类对象替换成它的字类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个字类对象的话，那么它不一定能够使用基类对象，里氏替换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用字类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时在确定其子类类型，用子类对象来替换父类对象。在使用时需要注意一下几个地方：
- 子类的所有方法必须在父类中声明，或子类必须实现父类中的所有方法，根据里氏替换原则，为了保住系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。
- 我们在运用里氏替换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现父类中声明的方法，运行时，子类实列替换父类实列，我们可以很方便的扩展系统的功能，同时无需修改原有的子类的代码，增加新的佛你功能我们可以通过增加一个新的子类来实现，里氏替换原则是开闭原则的具体实现手段之一。
4.依赖倒置原则
定义：高层模块不应该依赖底层模块，两个都应该依赖于抽象。抽象不应该依赖细节，细节应该依赖于抽象。在java中，抽象就是指接口或者抽象类，两者都是不能直接被实列化的。细节就是实现类，实现接口或者继承抽象类而产出的就是细节，也就是可以加上一个关键字new产生的对象，高层模块就是调用端，底层模块就是具体实现类。依赖倒置原则在java中的表现就是：模块间通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。如果与类直接依赖细节，那么就会直接耦合，那么修改时，就会同时修改依赖者代码，这样就限制了可扩展性。
5.迪米特原则
定义：一个软件实体应当尽可能少得与其他实体发生相互作用。也称为最少知识原则。如果一个系统符合迪米特原则，那么其中某一个模块发生修改时，就会尽量少的影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特原则要求限制团建实体之间通信的宽度和深度。迪米特法则可降低系统的耦合毒，使得类与类保持松散的耦合关系。迪米特原则要求我们在设计系统时，应该尽量减少对象之前的交互，如果两个对象之间不必彼此通信，那么这两个对象就不应当发生任何的相互作用，如果其中一个对象需要调用另外一个对象的方法时，可以通过第三者来转发这个调用，简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度，在将迪米特原则运用到系统设计中时，要注意以下几点：
- 在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于服用，一个处在松耦合中的类一旦被修改，不会对关联的类照成太大的波动.
- 在类的结构设计上，每一个类都应当降低其成员变量和成员函数的访问权限，在类的设计上，只要有可能，一个类型应当设计成不变类，在对其他类的引用上，一个对象对其他对象的引用应当降到最低。
6.接口隔离原则
定义：一个类对另一个类的依赖应该建立在最小的接口上，建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量小，也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个庞大的接口供所有依赖它的类去调用。采用接口隔离原则对接口进行约束时要注意以下几点：
- 接口尽量小，但是要有限度，对接口进行细化哭提高程序设计灵活性，但是如果过小，则会照成接口数量过多，使设计复杂化，所以一定要适度。
- 为依赖接口的类定制服务，只暴露给调用的类需要的方法，它不需要的方法则隐藏起来，只有专注地为一个模块提供定制服务，才能建立最小的依赖关系，提高内聚，减少对外交互，使接口用最少的方法完成最多的事情。
