単一職責原則のモデルの黄金法則

デザインモードでは、いくつかの黄金の原則と見なされ、デザインモードはすべて黄金の原則をめぐって、コードまたはアーキテクチャの設計に対して相応の調整をしています.実は、これらのモデルの基礎は黄金の原則です.だから、これらの原則を詳しく解析します.今日は言ってください.単一職責原則です.
単一職責の原則を話す
単一職責の原則として、英語名はSRPといいます.つまり、Single reponsibility prinncipleです.私たちは字面から、この原則の表現の意味をもう十分理解しました.jsの中で、関数は永遠に1等の公民で、関数の代表したのは1部の職責です.一つの関数は一つの機能を完成して、最後に私達のjsプログラムに編み上げました.
前のパターンを基本的に整理しましたが、各パターンには多かれ少なかれいくつかの原則が含まれています.(編集できない)
人の話ですか?～私達は読めません!!!すみません、これは栗です.
単一職責と代理
直接乾物に来る.プロキシモードでは、この例を覚えていますか?画像の読み込み
プロキシモードが導入されていないときはこう書きます.

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には二つの原則があります.一つは本体にsrcを設置することです.もう一つは、Imgノードを仮想的に構築して画像をロードします.最後にロードが完了した時に本体のsrcを修正します.このように書くと間違いないです.彼の需要がない前に、このコードは比較的完璧です.しかし、あなたの産経は永遠にこのように一心不乱になることはできなくて、時には、あなたにロードするピクチャーが交換することを待つことができて、時には.
したがって、拡張性を考慮するために、単一職責原則を参考にして、次のように修正することができます.

//      ，      src    
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");

このように、本体にsrcをセットする機能は完璧に保留できます.
単一の職責とノードレンダリング
この問題にみんながあったと信じて、バックグラウンドにデータを要求してから、ページにレンダリングします.具体的に言えば、このような
本の情報には、彼のimg、title、authorの3つの部分があります.私たちの役割は、バックグラウンドに関連するデータを要求し、データをページにレンダリングすることです.私達の現在の職責は二つです.データを取って、データをレンダリングします.

var data = {
    img:"http://7xpsmd.com1.z0.glb.clouddn.com/16-1-24/19756676.jpg",
    title:"JS    "，
    author:"David Flaagan"
}

http.getBooks = function(url,callback){
    $.ajax(url)
    .then((data)=>{
        itera(data,callback);
    })
}
//   ，   data      ,        
var itera = function(data,callback){
    for(var i = 0,book;book = data[i++];){
        callback(data); //  data
    }
}
//    ，      
http.getBooks("www.example.com",function(){
    console.log("    ");
});

簡単な流れはこのようなものです.大きな面から見れば、確かに役割は二つしかありません.しかし、実現すると、本体には一つのforサイクルが組み込まれています.ノード関数を追加して持ってきます.このように結合性が大きくなります.したがって、ここには一つのローズマリーモードを追加して、ローズデーを循環させます.つまり、私のレンダリング関数はローズデージェネレータだけと関係が発生します.あなたのもとのajax要請はどのように実現されたのか分かりません.
職責の区分が一目でわかるものではないようですが、どう見ますか?
実は、私も知らないで、感じを見て、時には感じて来て、さえぎることができません.
取得リストの例
上述したように、SRPはモードアプリケーションの中で最も簡単なものであり、同様に応用が最も広いものである.振り返ってみますと、私たちは一例を書く時、通常のフォーマットは一つのクローズド＋一つの変数は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());  //   single

ここでは、単例類と取得単例の工場を分けてください.工場は無制限に使用できます.単例類でも彼の独特な行動を実行できます.このようにするのは素晴らしいです.もちろん、私達も違う工場を作って出てきます.
これは機能関数をキャッシュした結果で、アプリケーションシーンは主に追加のテンプレートファイルをロードする時に使用されます.

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

AOPのSRP
AOPは人の数が多いレベルを見るべきです.多くのところで彼、職責チェーンモード、装飾者モードなどを使ったことがあります.AOPもSRPの原則を完璧に体現しています.
まず、彼自身の書くものはすべてSRPの原則に合っています.

Function.prototype.before = function(fn){
    var _this = this;
    return function(){
        fn.apply(this,arguments);  //  Boolean，          
        return    _this.apply(this,arguments);
    }
}

AOPの概念を抽象化して、そのままbeoffを使うことができます.
通常、私たちはAOPを利用して、urlパラメータを修正して、権限を伝達する業務に活用できます.例えば、インタフェースのアドレスはもう完璧ですが、あなたのリーダーはおとめ座です.今は二つの道があります.直接にルートを変更するか、それともAOPを使って変更することができます.お正月のために、私はAOPを使います.おとめ座の後に何をするか分からないからです.

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

beforeを使って動的に織り込んで、乙女座を完璧に解決します.
SRP原則はどうやって作りますか?
実を言うと、本当に分かりません.ここにはいくつかの良い経験があります.あまりにもデザインを追求すると、あなたのプログラムの複雑さが爆発します.適当な時間に、適当な位置で使うのがSRPの難点です.
SRP原則を使う時ではないと言います.

は、行為と動作を区別する.私たちはSRPで動作を区別します.行為とは、divを作成し、クラスを追加し、atrを修正するなどの基本的な操作です.動作は、要求を送信する、ノードをレンダリングするなど、行為を組み合わせて達成する効果です.このような比較的抽象的な動作.

は第一感覚を主として、このように職責を区分するのが間違いないと感じたら、SRPを使うのがちょうどいいです.いずれにしても、自分で掘った穴を自分で取り戻す必要があります.再構築されたコードがないと、いつまでも見られないことを知るべきです.

実際には、正面から歩いてはいけません.逆思考を試してみてもいいです.考えてみてください.普段はSRPの原則を使っていないのはいつですか?このようにあなたの思考の発展を助けることができて、あなたに良いコードを書くことができます.