设计原则

单一职责

工作中常会看见一个Activity的代码有千余行，每每看见这样的代码都会觉得头大。
单一职责顾名思义，每个模块应该只有一个职责。这里的“只有一个职责”并不是说每个模块只有一个函数(方法)，而是说每个模块承担的职责应该是高度相关的，或者说任何一个软件模块都应该只对一类行为负责。
形象一点的例子是Git的代码冲突。常规情况项目一个模块由一个人负责；这里面可以把开发者看作一类方法，因为他们会对模块进行修改；当模块含有多个类别的方法（多个开发者），那么一个方法的修改（一个开发者修改代码），就可能其他类的方法（其他开发者）产生影响，从而出现冲突。

现在的台式电脑如果出了故障是很好维修的，内存、硬盘、CPU、主板等组件可以随意替换。这里的内存硬盘等组件，就是单一职责的体现。内存只负责数据的临时读写，硬盘负责持久性读写，CPU负责运算...假使这些组件没有按照单一职责的设计实现而使用高度耦合的设计，比如CPU和硬盘集成在一起，那么CPU坏了也需要将硬盘换掉。
单一职责符合人的认知常识，有助于提高内聚，降低耦合。听上去简单，但是实现上并不简单，如何划分不同职责，需要开发人员有一定的分析设计能力。

接口隔离

接口隔离，意为 实现 不应该依赖于 其 不需要的方法。
画个图

类A依赖于接口中的Function1和Function3，A+是该依赖的实现；
类C依赖于接口中的Function1、Function2和Function4，B+是该依赖的实现。
由图可见，类A虽然依赖于接口，但是并不依赖于接口中的Function2和Function4，同理类B也一样，这就不符合接口隔离的原则，因为A+和B+实现了不需要的方法。
因此我们可以将接口细分，实现接口隔离：

接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中，将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
说到这里，很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构。 采用接口隔离原则对接口进行约束时，要注意以下几点：

• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。 运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。

感觉这个不太常用，会导致Project很乱

里氏替换

里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能

迪米特原则

//TODO

合成复用

//TODO

依赖倒置

模块的实现不应该相互依赖，而应该依赖于抽象。
面向接口编程，不要面向实现编程。

开闭原则

//TODO