摘要：今天說(shuō)一下，單一職責(zé)原則。比如，接口的地址本來(lái)已經(jīng)很完美了，但是你的是處女座最討厭處女座非要給路由添加幾個(gè)以保證后臺(tái)數(shù)據(jù)的安全。為了過(guò)年，我會(huì)選擇使用，因?yàn)椴恢捞幣院髸?huì)做出什么傻事來(lái)。此時(shí)的使用動(dòng)態(tài)織入后，可以完美的解決處女座。

在設(shè)計(jì)模式中，有著幾條視為黃金原則，設(shè)計(jì)模式都是圍繞黃金原則，對(duì)代碼或者說(shuō)是架構(gòu)設(shè)計(jì)做出一些相應(yīng)的調(diào)整，久而久之，GoF 4人組，發(fā)現(xiàn)其實(shí)有些設(shè)計(jì)思想可以稱為模式，能實(shí)現(xiàn)代碼復(fù)用的好處，從而設(shè)計(jì)模式出世。其實(shí)，這些模式的基石就是黃金原則，所以，接下來(lái)會(huì)對(duì)這些原則進(jìn)行詳細(xì)的解析。今天說(shuō)一下，單一職責(zé)原則。

單一職責(zé)原則，英文名叫做SRP.即,Single responsibility principle (裝個(gè)逼). 我們從字面上，差不多已經(jīng)完全可以理解這個(gè)原則所要表達(dá)的意思。在js中，函數(shù)永遠(yuǎn)是一等公民，而函數(shù)所代表的就是一份職責(zé)。 一個(gè)函數(shù)完成一個(gè)功能，最后編織成了我們的js程序。

前面差不多把模式基本的梳理了一遍，要知道，每個(gè)模式里面或多或少會(huì)包含一些原則。。。(我編不下去)

說(shuō)人話呀~~~ 俺們看不懂!!!
客官對(duì)不起，小的這就給你上栗子。

直接來(lái)干貨。在代理模式中，大家還記得這個(gè)例子嗎？圖片的加載

在未引入代理模式的時(shí)候是這樣寫(xiě)的

var delayload = (function(){
    var img = document.querySelector("#img");
    img.src = "loading.gif";
    var newImg = document.createElement("img");
    newImg.onload = function(){
        img.src = newImg.src;
    }
    return function(src){
        newImg.src = src;
    }
})();
delayload("jimmy.jpg");

我們分析一下，在delayload里面存在了兩個(gè)原則，一個(gè)是給本體的img設(shè)置src,還有一個(gè)是，虛擬構(gòu)建一個(gè)Img節(jié)點(diǎn)來(lái)加載圖片，最后在加載完成的時(shí)候，修改本體的src. 這樣寫(xiě)，沒(méi)錯(cuò)，如果在沒(méi)有其他的需求之前，這個(gè)代碼可以算是比較完美的。 但是，你的產(chǎn)經(jīng)永遠(yuǎn)不會(huì)這么一心一意，有時(shí)候，會(huì)讓你把，等待加載的圖片換掉，有時(shí)候。。。

所以為了擴(kuò)展性考慮，我們可以參考單一職責(zé)原則，修改如下：

//將背景圖設(shè)置，和圖片加載的src修改分開(kāi)
var delayload = (function(){
    var img = document.querySelector("#img");
    return {
        setSrc:function(src){
            img.src = src;
        }
    }
})();
var proxy = (function(){
    var img = document.createElement("img");
    img.onload = function(){
        delayload.setSrc(img.src);
    }
    return {
        setSrc:function(src){
            delayload.setSrc("loading.gif");
            img.src = src;
        }
    }
})();
proxy.setSrc("jimmy.jpg");

這樣一方面，對(duì)于本體img設(shè)置src的功能我們可以完美的保留下來(lái)。

相信大家都遇到這個(gè)問(wèn)題，向后臺(tái)請(qǐng)求數(shù)據(jù)，然后渲染到頁(yè)面上。說(shuō)具體一點(diǎn)就是，像這樣的

一本圖書(shū)的信息，有他的img,title,author這3部分內(nèi)容。 我們的職責(zé)就是，向后臺(tái)請(qǐng)求相關(guān)的數(shù)據(jù),然后將數(shù)據(jù)渲染到頁(yè)面。而我們目前的職責(zé)就是兩個(gè)，獲取數(shù)據(jù)，然后渲染數(shù)據(jù)。

var data = {
    img:"http://7xpsmd.com1.z0.glb.clouddn.com/16-1-24/19756676.jpg",
    title:"JS權(quán)威指南"，
    author:"David Flaagan"
}

http.getBooks = function(url,callback){
    $.ajax(url)
    .then((data)=>{
        itera(data,callback);
    })
}
//要知道，這里的data可能不只一個(gè),我們需要進(jìn)行遍歷
var itera = function(data,callback){
    for(var i = 0,book;book = data[i++];){
        callback(data); //渲染data
    }
}
//請(qǐng)求數(shù)據(jù)，并且渲染數(shù)據(jù)
http.getBooks("www.example.com",function(){
    console.log("渲染數(shù)據(jù)");
});

簡(jiǎn)單流程是這樣的，從大的方面來(lái)看，職責(zé)確實(shí)只有兩個(gè)，但是我們實(shí)現(xiàn)的時(shí)候，會(huì)發(fā)現(xiàn)，本體中嵌套一個(gè)for循環(huán)，會(huì)把添加節(jié)點(diǎn)函數(shù)帶入，這樣耦合性會(huì)增大，所以這里加了一個(gè)迭代器模式，讓迭代器來(lái)表示循環(huán)，即，我的渲染函數(shù)只和迭代器發(fā)生關(guān)系，而你原來(lái)的ajax請(qǐng)求是怎么實(shí)現(xiàn)的我并不清楚。

可以看出，職責(zé)的劃分不是一眼就能看出來(lái)的，那怎么看嘞？

其實(shí)，我也不知道，看感覺(jué)唄，有時(shí)候感覺(jué)來(lái)了，擋都擋不住.

上面已經(jīng)說(shuō)過(guò)了，SRP是在模式應(yīng)用中，最簡(jiǎn)單的一個(gè)，同樣也是應(yīng)用最廣的一個(gè)。回想一下，我們?cè)趯?xiě)單例的時(shí)候,通常的格式是一個(gè)閉包+一個(gè)變量就over了。

var Weather = function() {}
var getSingle = (function() {
    var single;
    return function(obj) {
        if (single === undefined) {
            return single = obj;
        }
        return single;
    }
})();
var weather1 = getSingle(new Weather());  //原始的Weather
var weather2 = getSingle(new Weather());  //存儲(chǔ)的single

這里，將單例類和獲取單例的工廠分開(kāi)來(lái)。 工廠可以無(wú)限制使用，單例類也可以執(zhí)行他獨(dú)特的行為。 這樣做是極好的。 當(dāng)然，我們也可以創(chuàng)造不同的工廠出來(lái)。

這個(gè)是緩存一個(gè)功能函數(shù)的結(jié)果，應(yīng)用場(chǎng)景主要在加載額外的模板文件時(shí)，使用

var getSingle = function(fn){
    var result;
    return function(){
        return result || (result = fn.apply(this,arguments));
    }
}

AOP我們應(yīng)該算是閱人無(wú)數(shù)的級(jí)別了， 在很多地方都是用過(guò)他，職責(zé)鏈模式，裝飾者模式等。而AOP也是完美體現(xiàn)SRP原則的。

首先，他本身的書(shū)寫(xiě)都是符合SRP原則

Function.prototype.before = function(fn){
    var _this = this;
    return function(){
        fn.apply(this,arguments);  //值為Boolean，表示是否繼續(xù)向下傳遞
        return    _this.apply(this,arguments);
    }
}

將AOP的概念抽象化，然后就可以直接使用beofre。

通常我們可以將AOP運(yùn)用到，修改url參數(shù)，傳遞權(quán)限的業(yè)務(wù)上面。 比如，接口的地址本來(lái)已經(jīng)很完美了，但是你的leader是處女座(最討厭處女座),非要給url路由添加幾個(gè)token以保證后臺(tái)數(shù)據(jù)的安全。現(xiàn)在有兩條路給你，要么直接改動(dòng)路由，要么可以使用AOP進(jìn)行改動(dòng)。 為了過(guò)年，我會(huì)選擇使用AOP，因?yàn)椴恢捞幣院髸?huì)做出什么傻事來(lái)。

function dealUrl(url){
    url+=param.getToken();
}
http.ajax = http.ajax.before(dealUrl);
http.ajax("www.example.com");   //此時(shí)的Url = www.example.com?token=23jkfd3kjfdksjfkjds

使用before動(dòng)態(tài)織入后，可以完美的解決處女座。

實(shí)話說(shuō)，我真的不知道。 我這里只有幾條我認(rèn)為比較好的經(jīng)驗(yàn)給大家，因?yàn)槿绻^(guò)分追求設(shè)計(jì)的話，你的程序復(fù)雜度將會(huì)爆炸!!!。 在合適的時(shí)間，合適的位置使用，這才是SRP的難點(diǎn)。

說(shuō)一下，不是用SRP原則的時(shí)候把。

分清行為和動(dòng)作。 我們只是用SRP區(qū)分動(dòng)作，而不過(guò)分劃分行為。行為就是: 創(chuàng)建div,添加類，修改attr等基本操作。 動(dòng)作就是 將行為組合在一起達(dá)到的效果，比如發(fā)送請(qǐng)求，渲染節(jié)點(diǎn)。 這類比較抽象的動(dòng)作。

要以第一感覺(jué)為主，如果感覺(jué)這樣劃分職責(zé)沒(méi)錯(cuò)，使用SRP恰到好處，那就干吧。 反正以后自已挖的坑自己也得補(bǔ)回來(lái)，要知道，沒(méi)有重構(gòu)過(guò)的代碼，永遠(yuǎn)是不能看的(說(shuō)的是我。。。)。

其實(shí)有時(shí)候，從正面走不行，我們可以嘗試一下逆向思維，想想，你平常沒(méi)有使用SRP原則是什么時(shí)候就可以了。這樣能夠幫助你思維的發(fā)展，也能讓你寫(xiě)出一手好代碼。