单一职责原则之模式的黄金法则

在设计模式中，有着几条视为黄金原则，设计模式都是围绕黄金原则，对代码或者说是架构设计做出一些相应的调整，久而久之，GoF 4人组，发现其实有些设计思想可以称为模式，能实现代码复用的好处，从而设计模式出世。其实，这些模式的基石就是黄金原则，所以，接下来会对这些原则进行详细的解析。今天说一下，单一职责原则。

谈谈单一职责原则

单一职责原则，英文名叫做SRP.即,Single responsibility principle (装个逼). 我们从字面上，差不多已经完全可以理解这个原则所要表达的意思。在js中，函数永远是一等公民，而函数所代表的就是一份职责。一个函数完成一个功能，最后编织成了我们的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里面存在了两个原则，一个是给本体的img设置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");

这样一方面，对于本体img设置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的概念抽象化，然后就可以直接使用beofre。

通常我们可以将AOP运用到，修改url参数，传递权限的业务上面。比如，接口的地址本来已经很完美了，但是你的leader是处女座(最讨厌处女座),非要给url路由添加几个token以保证后台数据的安全。现在有两条路给你，要么直接改动路由，要么可以使用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,添加类，修改attr等基本操作。动作就是将行为组合在一起达到的效果，比如发送请求，渲染节点。这类比较抽象的动作。
要以第一感觉为主，如果感觉这样划分职责没错，使用SRP恰到好处，那就干吧。反正以后自已挖的坑自己也得补回来，要知道，没有重构过的代码，永远是不能看的(说的是我。。。)。

其实有时候，从正面走不行，我们可以尝试一下逆向思维，想想，你平常没有使用SRP原则是什么时候就可以了。这样能够帮助你思维的发展，也能让你写出一手好代码。

原文链接：https://www.f2er.com/javaschema/284187.html