设计模式之六大原则

设计模式的重要性不言而喻，它关系到项目的扩展与后期维护，架构的设计离不开设计模式的应用。

单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。

这句话的理解是要把类的职责进行比较详细的拆分，尽可能的做到一个类只负责一类的事物。举一个例子：Activity中我们实现了数据的处理和页面的点击事件两个职责，如果我们要修改数据或是修改点击事件时，都需要操作一个Activity，这样就对单一职责原则有所违背。

开放封闭原则

类、模块、函数等应该是可以扩展的，但是不可修改的。

开放封闭是两个含义，一个是对扩展是开放的，另一个是对修改时封闭的。项目的开发过程中，功能和需求的改变时有发生，这就要求我们在设计程序的时候，在保证稳定的前提下，通过扩展的方式来实现变化。

里氏替换原则

所有应用基类（父类）的地方必须能透明的使用其子类的对象。

里氏替换原则的实现依靠了OOP中的继承特性，父类对象可以指向子类的实现，所以使用父类的所有地方，都可以换成子类，反过来就是不能成立的了；因此在程序中我们尽可能的使用父类来定义对象，在实例对象的时候在根据具体的要求，以不同的子类来实现。
在使用里氏替换原则的时候，我们需要注意一下几点：

1. 子类必须实现父类声明的所有方法；
2. 尽量把父类设计成接口或抽象类；

里氏替换原则时开闭原则的具体实现手段之一。

依赖倒置原则

高层模块不应依赖低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该应该依赖于抽象。

在Java中，抽象指的是接口或抽象类，两者都不可以直接实例化；细节就是实现类，用来实现接口或者抽象类；高层模块就是调用端，低层模块就是具体的实现类。模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，它们的依赖关系是通过接口或抽象类产生的。如果类之间直接依赖细节，就会直接耦合，限制了可扩展性。

迪米特原则

一个类应该对其他类有最少的了解。

这也被称为最少知识原则。迪米特原则要求我们在设计程序的时候，应该尽量减少对象之间的交互，我们可以使用第三者作为两个对象之间的桥梁，实现对象之间的调用。
在使用迪米特原则时，应注意一下几点：

1. 应当创建松耦合的类，类之间的耦合度越低，就越有利于复用。
2. 每一个类都应当尽量降低其成员变量和成员函数的访问权限。
3. 一个对象对其他对象的引用应当降到最低。

接口隔离原则

两个的类之间的依赖应该建立在最小的接口上。

通俗的来说就是类不应该依赖它不需要的接口。建立单一接口，不要建立庞大臃肿的接口；尽量细化接口，接口中的方法尽量的少。接口隔离原则的目的是系统解开耦合，从而容易重构和更改。