单一职责原则
单一职责原则的英文名称是Single Responsibility Principle，简称SRP。它的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。
比如网络请求，在初始封装时
/**
* get 请求数据列表
* @param context 上下文
* @param url 访问路径
* @param params 访问参数
*/
public static <T> void get(Context context, String url, Map<String, Object> params, final HttpCallBack<T> callback) {
OkHttpClient mOkHttpClient = new OkHttpClient();
// 公共参数拼接
params.put("token", "xxxxxxx");
params.put("taype", "android");
//可以省略，默认是GET请求
Request request = requestBuilder.build();
// 异步请求数据
mOkHttpClient.newCall(request).enqueue(new Callback() {
@Override
public void onFailure(Call call, final IOException e) {
// 失败
callback.onFailure(e);
}
@Override
public void onResponse(Call call, Response response) throws IOException {
final String resultJson = response.body().string();
// json 转换，有无数据列表，缓存处理
}
});
}
使用单一职责原则拆分
public class HttpUtils {
private OKHttpRequest mHttpRequest;
private HttpUtils(Context context) {
mHttpRequest = new OKHttpRequest();
mHttpRequest.with(context);
}
// 省略一些代码 ...
}
开闭原则
开闭原则的英文全称是Open Close Principle，简称OCP，它是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。我的理解是对于原来写好的代码里面是不可修改，但是对于外部又是可扩展的。
public class HttpUtils {
// 这个可以在 application 中去初始化
private static IHttpRequest mInitHttpRequest;
private IHttpRequest mHttpRequest;
public static void initHttpRequest(IHttpRequest httpRequest) {
mInitHttpRequest = httpRequest;
}
// 如果有两种的情况下 比如 volley 下载文件并不是很屌 ，那么可以换成 OKHttp
public HttpUtils httpRequest(IHttpRequest httpRequest) {
this.mHttpRequest = httpRequest;
return this;
}
// 省略部分代码 ......
public <T> void execute(HttpCallBack<T> callback) {
// 如果没有指定，那么就用 application 中初始化的
if(mHttpRequest == null){
mHttpRequest = mInitHttpRequest;
}
mHttpRequest.get(mContext, mParams, mUrl, mCache, callback);
}
}
IHttpRequest 代码
public interface IHttpRequest {
/**
* post 提交
*
* @param context
* @param params
* @param url
* @param cache
* @param callback
* @param <T>
*/
<T> void post(Context context, Map<String, Object> params, String url, final boolean cache, final HttpCallBack<T> callback);
/**
* get 提交
*
* @param context
* @param params
* @param url
* @param cache
* @param callback
* @param <T>
*/
<T> void get(Context context, Map<String, Object> params, String url, final boolean cache, final HttpCallBack<T> callback);
}
OKHttpRequest 代码
public class OKHttpRequest implements IHttpRequest {
private HttpCache mHttpCache;
private OkHttpClient mOkHttpClient;
public OKHttpRequest() {
mHttpCache = new HttpCache();
mOkHttpClient = new OkHttpClient();
}
@Override
public <T> void post(Context context, Map<String, Object> params, String url, boolean cache, HttpCallBack<T> callback) {
// 省略部分代码 ......
}
public <T> void get(Context context, Map<String, Object> params, String url, final boolean cache, final HttpCallBack<T> callback) {
// 省略部分代码 ......
}
}
XUtilsRequest 代码
public class XUtilsRequest implements IHttpRequest {
private HttpCache mHttpCache;
public XUtilsRequest() {
mHttpCache = new HttpCache();
}
@Override
public <T> void post(Context context, Map<String, Object> params, String url, boolean cache, HttpCallBack<T> callback) {
// 省略部分代码 ......
}
public <T> void get(Context context, Map<String, Object> params, String url, final boolean cache, final HttpCallBack<T> callback) {
// 省略部分代码 ......
}
}
Application 代码
public class BaseApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
PreferencesUtil.getInstance().init(this);
x.Ext.init(this);
// 初始化指定网络请求
HttpUtils.initHttpRequest(new XUtilsRequest());
}
}
里氏替换原则
里氏替换原则英文全称是Liskov Substitution Principle，简称LSP。我们知道，面向对象的语言的三大特点是继承、封装、多态，里氏替换原则就是依赖于继承、多态这两大特性。里氏替换原则简单来说就是，所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类能出现的地方子类就可以出现。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
// 1. 今天所写的初始化请求
HttpUtils.initHttpRequest(new XUtilsRequest());
HttpUtils.initHttpRequest(new OKHttpRequest());
// 2. RecyclerView 的 LayoutMananger
mRecyclerView.setLayoutManager(new LinearLayoutManager(this));
mRecyclerView.setLayoutManager(new GridLayoutManager(this,3));
使用的地方非常之多，setLayoutManager 的源码大家可以自己去了解一下，上面的代码就很好的反应了里氏替换原则，XUtilsRequest、OKHttpRequest 都可以替换 IHttpRequest 的工作。IHttpRequest 建立了 post 请求，get 请求，上传，下载的接口规范，XUtilsRequest 等根据接口规范实现了相应的功能，用户只需要在 Application 中指定具体的缓存对象就可以动态地替换 IHttpRequest 中的请求。这就使得网络请求具有了无线的可能性，也就是保证了可扩展性。
里氏替换原则和开闭原则有点相似，但仔细理解他们之间是不同的概念，只能够说是有时候开闭原则和里氏替换原则往往生死相依、不弃不离，通过里氏替换来达到对扩展开放，对修改关闭的效果，这两个原则其实就是面向对象思想中的抽象。
依赖倒置原则
依赖倒置原则英文全称是Dependence Inversion Principle，简称DIP。依赖反转原则指代了一种特定的解耦形式，高层模块不依赖低层次模块的细节，说白了高层次就是不依赖细节而是依赖抽象。那什么又是低层次什么是高层次？拿上面开闭原则那张图来讲，HttpUtils 是高层次，IHttpRequest、XUtilsRequest 和 OKHttpRequest 是低层次。刚开始 HttpUtils 是这么写的：
public class HttpUtils {
private OKHttpRequest mHttpRequest;
private HttpUtils(Context context) {
mHttpRequest = new OKHttpRequest();
mHttpRequest.with(context);
}
// 省略一些代码 ...
}
这个时候我们依赖的是具体的 OKHttpRequest，这种情况下很明显我们依赖的是具体的细节， 在开闭原则过后，我们 HttpUtils 是这么写的。
public class HttpUtils {
// 这个可以在 application 中去初始化
private static IHttpRequest mInitHttpRequest;
private IHttpRequest mHttpRequest;
public static void initHttpRequest(IHttpRequest httpRequest) {
mInitHttpRequest = httpRequest;
}
// 如果有两种的情况下 比如 volley 下载文件并不是很屌 ，那么可以换成 OKHttp
public HttpUtils httpRequest(IHttpRequest httpRequest) {
this.mHttpRequest = httpRequest;
return this;
}
// 省略部分代码 ......
public <T> void execute(HttpCallBack<T> callback) {
// 如果没有指定，那么就用 application 中初始化的
if(mHttpRequest == null){
mHttpRequest = mInitHttpRequest;
}
mHttpRequest.get(mContext, mParams, mUrl, mCache, callback);
}
}
这个时候我们依赖的就已经不在是具体的细节了，而是抽象的 IHttpRequest ，具体的实现我们是在 Application 中配置的，可以配置 Okhttp 或者 xUtils 等等。从上面这几个来看要让整个系统更加灵活，似乎一直都是抽象的功劳。
接口隔离原则
接口隔离原则英文全称是InterfaceSegregation Principles，简称ISP。它的定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署，让客户端依赖的接口尽可能地小。
最少知识原则
最少知识原则又称为迪米特原则英文全称为Law of Demeter，简称LOD，虽然名字不同，但描述的是同一个原则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
