目录
创建型模式
结构型模式
行为型模式
一、单一职责原则
定义
一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。
1. 一般我们写一个网络请求可能是这样
public class HttpUtils {
private HttpUtils() {
}
public static <T> void get(Context context, String url, Map<String, Object> params, final HttpCallBack<T>
callback, final boolean cache) {
OkHttpClient mOkHttpClient = new OkHttpClient();
// 公共参数
params.put("app_name", "joke_essay");
params.put("version_name", "5.7.0");
params.put("device_platform", "android");
final String jointUrl = Utils.jointParams(url, params); //打印
// 缓存问题
Log.e("Post请求路径：", jointUrl); // 缓存写到 SP 里面，多级缓存（内存中 30条,数据库 ，文件中 ）
final String cacheJson = (String) PreferencesUtil.getInstance().getParam(jointUrl, "");
// 写一大堆处理逻辑 ，内存怎么扩展等等
if (cache && !TextUtils.isEmpty(cacheJson)) {
Log.e("TAG", "从缓存中获取数据");
Gson gson = new Gson();
T objResult = (T) gson.fromJson(cacheJson,
Utils.analysisClazzInfo(callback));
callback.onSuccess(objResult);
return;
}
Request.Builder requestBuilder = new Request.Builder().url(jointUrl).tag(context);
//可以省略，默认是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();
Log.e("TAG", resultJson.equals(cacheJson) + "");
Log.e("TAG", resultJson + "");
if (cache && resultJson.equals(cacheJson)) {
return;
}
Gson gson = new Gson();
T objResult = (T) gson.fromJson(resultJson,
Utils.analysisClazzInfo(callback));
callback.onSuccess(objResult);
if (cache) {
PreferencesUtil.getInstance().saveParam(jointUrl, resultJson);
}
}
});
}
}
2. 然后这样调用
Map<String, Object> params = new HashMap<>();
// 特定参数
params.put("iid", 6152551759L);
params.put("aid", 7);
HttpUtils.get(this, ConstantValue.UrlConstant.HOME_DISCOVERY_URL, params, new HttpCallBack<DiscoverListResult>() {
@Override
public void onFailure(Exception e) {
// 失败
}
@Override
public void onSuccess(DiscoverListResult result){
if (result.isOK()) {
// 没有列表数据的情况, 打印 Toast 或者做一些其他处理
} else {
// 有数据列表的情况，显示列表
showListData(result);
}
}
},true);
3. 导致问题
所有的功能都写在一个类里，这样随着功能的增多，HttpUtils 类会越来越大，代码也越来越复杂。HttpUtils简直就没有设计可言，更不要说扩展性、灵活性了。
4. 单一职责原则入场
我们将HttpUtils进行拆分，一个类只负责一个职责。
image
5. HttpUtils
public class HttpUtils {
private OKHttpRequest mHttpRequest;
public <T> void request() {
request(null);
}
public <T> void request(final HttpCallBack<T> callback) {
// 异常判断
mHttpRequest.get(mContext, mUrl, mParams, callback, true);
}
//省略其他代码
}
6. OKHttpRequest
public class OKHttpRequest {
private HttpCache mHttpCache;
public OKHttpRequest() {
mHttpCache = new HttpCache();
}
// 参数还是很多
public <T> void get(Context context, String url, Map<String, Object> params,final HttpCallBack<T> callback, final boolean cache) {
OkHttpClient mOkHttpClient = new OkHttpClient();
}
//省略其他代码
}
7. HttpCache
public class HttpCache {
public void saveCache(String finalUrl, String resultJson) {
PreferencesUtil.getInstance().saveParam(finalUrl, resultJson);
}
public String getCache(String finalUrl) {
return (String) PreferencesUtil.getInstance().getParam(finalUrl, "");
}
}
二、开闭原则
定义
软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。我的理解是对于原来写好的代码里面是不可修改，但是对于外部又是可扩展的。其实就是多了一个接口而已。
1. 上面代码存在问题
如果把xutils换成OkHttp，但是我没想过要去改每个接口，比如后来接着 Retrofit又出来了，以后还指不定要出一些什么，我想能不能再写得强大一些，可以切换，而不用改动原来的代码。
2. 修改后的类图
image
3. 开闭原则入场
新增IHttpRequest接口
/**
* @author 512573717@qq.com
* @created 2018/8/22 上午10:49.
*/
public interface IHttpRequest {
<T> void get(Context context, String url, Map<String, Object> params,
final HttpCallBack<T> callback, final boolean cache);
<T> void post(Context context, String url, Map<String, Object> params,
final HttpCallBack<T> callback, final boolean cache);
<T> void download(Context context, String url, Map<String, Object> params,
final HttpCallBack<T> callback);
<T> void upload(Context context, String url, Map<String, Object> params,
final HttpCallBack<T> callback);
}
4. XUtilsRequest
public class XUtilsRequest implements IHttpRequest {
private SPHttpCache mHttpCache;
public XUtilsRequest() {
mHttpCache = new SPHttpCache();
}
// 参数还是很多
public <T> void get(Context context, String url, Map<String, Object> params,
final HttpCallBack<T> callback, final boolean cache) {
RequestParams requestParams = new RequestParams();
x.http().get(requestParams, new org.xutils.common.Callback.CommonCallback<String>() {
});
}
5. OKHttpRequest
public class OKHttpRequest implements IHttpRequest{
private SPHttpCache mHttpCache;
public OKHttpRequest() {
mHttpCache = new SPHttpCache();
}
// 参数还是很多
public <T> void get(Context context, String url, Map<String, Object> params,
final HttpCallBack<T> callback, final boolean cache) {
OkHttpClient mOkHttpClient = new OkHttpClient();
}
}
6. HttpUtils
public class HttpUtils {
private IHttpRequest mHttpRequest;
private static IHttpRequest mInitHttpRequest;
public static HttpUtils with(Context context){
return new HttpUtils(context);
}
public HttpUtils httpRequest(IHttpRequest httpRequest){
mHttpRequest = httpRequest;
return this;
}
public <T> void request(){
request(null);
}
public <T> void request(final HttpCallBack<T> callback){
if(mHttpRequest == null){
mHttpRequest = mInitHttpRequest;
}
// 异常判断
mHttpRequest.get(mContext,mUrl,mParams,callback,true);
}
}
7. Client
HttpUtils.with(this).cache(true).get().httpRequest(new OKHttpRequest()).url(ConstantValue.UrlConstant.HOME_DISCOVERY_URL).param("iid", 6152551759L).param("aid", 7).request(
new HttpCallBack<DiscoverListResult>() {
@Override
public void onFailure(Exception e) {
// 失败
}
@Override
public void onSuccess(DiscoverListResult result){
if (result.isOK()) {
// 没有列表数据的情况, 打印 Toast 或者做一些其他处理
} else {
// 有数据列表的情况，显示列表
showListData(result);
}
}
});
8. 归纳
当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。我们尽量不要通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余。
三、里氏替换原则
定义
所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类能出现的地方子类就可以出现。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
代码体现
HttpUtils.initHttpRequest(new OKHttpRequest());
HttpUtils.initHttpRequest(new XUtilsRequest());
四、依赖倒置原则
定义
依赖反转原则指代了一种特定的解耦形式，高层模块不依赖低层次模块的细节，说白了高层次就是不依赖细节而是依赖抽象。
1. 刚开始代码是这样写的
public class HttpUtils {
private OKHttpRequest mHttpRequest;
private HttpUtils(Context context) {
mHttpRequest = new OKHttpRequest();
mParams = new HashMap<>();
this.mContext = context;
}
}
2. 用过开闭原则之后是这样写的
public class HttpUtils {
private IHttpRequest mHttpRequest;
public static HttpUtils with(Context context){
return new HttpUtils(context);
}
public HttpUtils httpRequest(IHttpRequest httpRequest){
mHttpRequest = httpRequest;
return this;
}
}
3. 总结
这个时候我们依赖的就已经不在是具体的细节了，而是抽象的 IHttpRequest ，具体的实现我们是在 Application 中配置的，可以配置 Okhttp 或者 xUtils 等等。从上面这几个来看要让整个系统更加灵活，似乎一直都是抽象的功劳。
五、接口隔离原则
定义
客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署，让客户端依赖的接口尽可能地小。
1. 我们在关闭文件流、Socket流通常是这样操作的
private void breakConnection() {
mReadFlag = false;
// 关闭输入流
if (mInStream != null) {
try {
mInStream.close();
} catch (IOException e) {
e.printStackTrace();
}
}
// 关闭输出流
if (mOutStream != null) {
try {
mOutStream.close();
} catch (IOException e) {
e.printStackTrace();
}
}
// 关闭Socket
if (mSocket != null) {
try {
mSocket.close();
mSocket = null;
} catch (Exception e) {
e.printStackTrace();
}
}
}
各种try…catch嵌套，都是些简单的代码，但是会严重影响代码的可读性，并且多层级的大括号很容易将代码写到错误的层级中。大家应该对这类代码也非常反感，那我们看看如何解决这类问题。我们看源码发现他们都有一个 close 方法，而且这个方法是 Closeable 接口的，也就是说上面的这几个类都是实现了 Closeable 接口，该接口标识了一个可关闭的对象。
2.都实现了Closeable接口
public abstract class InputStream implements Closeable {
}
public abstract class OutputStream implements Closeable, Flushable {
}
public class Socket implements java.io.Closeable {
}
3. Closeable
public interface Closeable extends AutoCloseable {
/**
* Closes this stream and releases any system resources associated
* with it. If the stream is already closed then invoking this
* method has no effect.
*
* <p> As noted in {@link AutoCloseable#close()}, cases where the
* close may fail require careful attention. It is strongly advised
* to relinquish the underlying resources and to internally
* <em>mark</em> the {@code Closeable} as closed, prior to throwing
* the {@code IOException}.
*
* @throws IOException if an I/O error occurs
*/
public void close() throws IOException;
}
4. 修改代码
private void breakConnection() {
mReadFlag = false;
// 关闭输入流
close(mInStream);
// 关闭输出流
close(mOutStream);
// 关闭Socket
close(mSocket);
}
/**
* 关闭 Closeable
* @param closeable
*/
private void close(Closeable closeable) {
if (closeable != null) {
try {
closeable.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
5. 总结
代码简洁了很多！保证了代码的重用性。close 方法的基本原理就是依赖于 Closeable 抽象而不是具体实现（这其实也是依赖倒置），并且建立在最小化依赖原则的基础，它只需要知道这个对象是可关闭，其他的一概不关心，也就是这里的接口隔离原则。
六、最少知识原则
定义
一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
