1.单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。
不要让一个类承担过多的职责。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这些耦合会导致脆弱的设计，当变化发生时，设计会遭受到破坏。
2.开放封闭原则
类、模块、函数等应该是可以拓展的，但是不可以修改。
对拓展开放，对修改封闭。在做程序设计时，需要保留足够的可拓展性，面对需求的变更时最好采取拓展的方式去实现，而非对原有类的修改。
3.里氏替换原则
所有引用父类的地方必须能够透明的使用其子类的对象。
在软件中将一个父类对象替换成其子类对象时，程序不应该产生任何错误和异常。里氏替换原则是实现开放封闭原则的重要方式之一。
4.迪米特原则
一个软件实体应当尽可能少的与其他实体发生相互作用。
也可以叫做最少知道原则。如果一个系统符合迪米特原则，那么当其中某一个模块发生修改时，就会尽量少的影响其他模块。迪米特原则要求我们在设计系统时，应该尽量减少对象之间的相互作用。系统设计时需要注意以下几点：
- 在类的划分上，应当尽量创建松耦合的类。类之间的耦合度越低，就越有利于复用。一个处在松耦合中的类一旦被修改，则不会对关联的类造成太大波及。
- 在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限。
- 在对其他类的引用上，一个对象对其他对象的引用应当将到最低。
5.依赖倒置原则
高层模块不应该依赖低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
模块间的依赖通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是通过接口或者抽象类产生的。如果类与类直接依赖细节，那么就会直接耦合。如此一来当修改时，就会同时修改依赖着代码，这样限制了可扩展性。
6.接口隔离原则
一个类对另一个类的依赖应该建立在最小的接口上。
建立单一接口，不要建立庞大臃肿的接口；尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图建立一个庞大的接口供所有依赖它的类调用。采用接口隔离原则对接口进行约束时，要注意以下几点：
- 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计的灵活性；但是如果过小，则会造成接口数量过多，使设计复杂化。所以，一定要适度。
- 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注的微一个模块提供定制服务，才能建立最小的依赖关系。
- 提高内聚，减少对外交互。接口方法尽量少用public修饰，接口是对外的承诺，承诺越少对系统的开发越有利，变更风险也会越少。
参考
- Android进阶之光