單一職責(zé)原則
單一職責(zé)原則的英文名稱是Single Responsibility Principle裸准，簡稱SRP。它的定義是：就一個類而言赔硫，應(yīng)該僅有一個引起它變化的原因炒俱。簡單來說，一個類中應(yīng)該是一組相關(guān)性很高的函數(shù)爪膊、數(shù)據(jù)的封裝权悟。
比如網(wǎng)絡(luò)請求，在初始封裝時
/**
* get 請求數(shù)據(jù)列表
* @param context 上下文
* @param url 訪問路徑
* @param params 訪問參數(shù)
*/
public static <T> void get(Context context, String url, Map<String, Object> params, final HttpCallBack<T> callback) {
OkHttpClient mOkHttpClient = new OkHttpClient();
// 公共參數(shù)拼接
params.put("token", "xxxxxxx");
params.put("taype", "android");
//可以省略推盛，默認(rèn)是GET請求
Request request = requestBuilder.build();
// 異步請求數(shù)據(jù)
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 轉(zhuǎn)換峦阁，有無數(shù)據(jù)列表，緩存處理
}
});
}
使用單一職責(zé)原則拆分
public class HttpUtils {
private OKHttpRequest mHttpRequest;
private HttpUtils(Context context) {
mHttpRequest = new OKHttpRequest();
mHttpRequest.with(context);
}
// 省略一些代碼 ...
}
開閉原則
開閉原則的英文全稱是Open Close Principle耘成，簡稱OCP榔昔，它是Java世界里最基礎(chǔ)的設(shè)計原則驹闰，它指導(dǎo)我們?nèi)绾谓⒁粋€穩(wěn)定的、靈活的系統(tǒng)撒会。開閉原則的定義是：軟件中的對象（類疮方、模塊、函數(shù)等）應(yīng)該對于擴展是開放的茧彤，但是，對于修改是封閉的疆栏。我的理解是對于原來寫好的代碼里面是不可修改曾掂，但是對于外部又是可擴展的。
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);
// 初始化指定網(wǎng)絡(luò)請求
HttpUtils.initHttpRequest(new XUtilsRequest());
}
}
里氏替換原則
里氏替換原則英文全稱是Liskov Substitution Principle，簡稱LSP若专。我們知道许蓖，面向?qū)ο蟮恼Z言的三大特點是繼承、封裝调衰、多態(tài)膊爪，里氏替換原則就是依賴于繼承、多態(tài)這兩大特性嚎莉。里氏替換原則簡單來說就是米酬，所有引用基類的地方必須能透明地使用其子類的對象。通俗點講趋箩，只要父類能出現(xiàn)的地方子類就可以出現(xiàn)赃额。但是，反過來就不行了叫确，有子類出現(xiàn)的地方跳芳，父類未必就能適應(yīng)。
// 1. 今天所寫的初始化請求
HttpUtils.initHttpRequest(new XUtilsRequest());
HttpUtils.initHttpRequest(new OKHttpRequest());
// 2. RecyclerView 的 LayoutMananger
mRecyclerView.setLayoutManager(new LinearLayoutManager(this));
mRecyclerView.setLayoutManager(new GridLayoutManager(this,3));
使用的地方非常之多竹勉，setLayoutManager 的源碼大家可以自己去了解一下飞盆，上面的代碼就很好的反應(yīng)了里氏替換原則，XUtilsRequest饶米、OKHttpRequest 都可以替換 IHttpRequest 的工作桨啃。IHttpRequest 建立了 post 請求，get 請求檬输，上傳照瘾，下載的接口規(guī)范，XUtilsRequest 等根據(jù)接口規(guī)范實現(xiàn)了相應(yīng)的功能丧慈，用戶只需要在 Application 中指定具體的緩存對象就可以動態(tài)地替換 IHttpRequest 中的請求析命。這就使得網(wǎng)絡(luò)請求具有了無線的可能性主卫，也就是保證了可擴展性。
里氏替換原則和開閉原則有點相似鹃愤，但仔細(xì)理解他們之間是不同的概念簇搅，只能夠說是有時候開閉原則和里氏替換原則往往生死相依、不棄不離软吐，通過里氏替換來達(dá)到對擴展開放瘩将，對修改關(guān)閉的效果，這兩個原則其實就是面向?qū)ο笏枷胫械某橄蟆?/p>
依賴倒置原則
依賴倒置原則英文全稱是Dependence Inversion Principle凹耙，簡稱DIP姿现。依賴反轉(zhuǎn)原則指代了一種特定的解耦形式，高層模塊不依賴低層次模塊的細(xì)節(jié)肖抱，說白了高層次就是不依賴細(xì)節(jié)而是依賴抽象备典。那什么又是低層次什么是高層次？拿上面開閉原則那張圖來講意述，HttpUtils 是高層次提佣，IHttpRequest、XUtilsRequest 和 OKHttpRequest 是低層次荤崇。剛開始 HttpUtils 是這么寫的：
public class HttpUtils {
private OKHttpRequest mHttpRequest;
private HttpUtils(Context context) {
mHttpRequest = new OKHttpRequest();
mHttpRequest.with(context);
}
// 省略一些代碼 ...
}
這個時候我們依賴的是具體的 OKHttpRequest拌屏，這種情況下很明顯我們依賴的是具體的細(xì)節(jié)， 在開閉原則過后术荤，我們 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);
}
}
這個時候我們依賴的就已經(jīng)不在是具體的細(xì)節(jié)了务唐，而是抽象的 IHttpRequest ，具體的實現(xiàn)我們是在 Application 中配置的带兜，可以配置 Okhttp 或者 xUtils 等等枫笛。從上面這幾個來看要讓整個系統(tǒng)更加靈活，似乎一直都是抽象的功勞刚照。
接口隔離原則
接口隔離原則英文全稱是InterfaceSegregation Principles刑巧，簡稱ISP。它的定義是：客戶端不應(yīng)該依賴它不需要的接口无畔。另一種定義是：類間的依賴關(guān)系應(yīng)該建立在最小的接口上啊楚。接口隔離原則將非常龐大、臃腫的接口拆分成為更小的和更具體的接口浑彰，這樣客戶將會只需要知道他們感興趣的方法恭理。接口隔離原則的目的是系統(tǒng)解開耦合，從而容易重構(gòu)郭变、更改和重新部署颜价，讓客戶端依賴的接口盡可能地小涯保。
最少知識原則
最少知識原則又稱為迪米特原則英文全稱為Law of Demeter，簡稱LOD周伦，雖然名字不同夕春，但描述的是同一個原則：一個對象應(yīng)該對其他對象有最少的了解。通俗地講专挪，一個類應(yīng)該對自己需要耦合或調(diào)用的類知道得最少及志，類的內(nèi)部如何實現(xiàn)、如何復(fù)雜都與調(diào)用者或者依賴者沒關(guān)系寨腔，調(diào)用者或者依賴者只需要知道他需要的方法即可困肩，其他的我一概不關(guān)心。類與類之間的關(guān)系越密切脆侮，耦合度越大，當(dāng)一個類發(fā)生改變時勇劣，對另一個類的影響也越大靖避。
