大师网-带你快速走向大师之路 解决你在学习过程中的疑惑,带你快速进入大师之门。节省时间,提升效率

JavaScript设计原则与编程技巧

1 设计原则概述

  1. UNIX/LINUX设计哲学》设计准则
    ① 小既是美。
    ② 每个程序只做一件事情。
    ③ 快速建立原型。
    ④ 舍弃高效率而取可移植性。
    ⑤ 避免强制性的图形化界面交互。
    ⑥ 让每个程序都成为过滤器。
    ⑦ 寻求90%的解决方案。
    注释:花20%的成本解决80%的需求。
  2. 五大设计原则(SOLID)
    S - 单一职责原则
    O - 开放封闭原则
    L - 李氏置换原则
    I - 接口独立原则
    D - 依赖倒置原则
  3. 单一职责原则
    一个程序只做好一件事情。
  4. 开放封闭原则
    对扩展开放,对修改封闭。
    增加需求时,扩展新代码,而非修改已有代码。
  5. 李氏置换原则
    子类能覆盖父类。
    父类能出现的地方子类就能出现。
  6. 接口独立原则
    保持接口的独立,避免出现“胖接口”。
  7. 依赖倒置原则
    面向接口编程,依赖于抽象而不依赖于具体。

2 单一职责原则

  1. 简介
    就一个类、对象以及方法而言,应该仅有一个引起它变化的原因。
    注释:单一职责原则定义为“引起变化的原因”。如果我们有两个动机去改写一个方法,那么这个方法就具有两个职责。
  2. 原则
    一个对象(方法)只做一件事情。
  3. 设计模式验证
    ① 代理模式
    图片预加载代理模式中,代理对象负责预加载职责,本体对象负责图片加载职责。
    ② 迭代器模式
    迭代器模式提供遍历访问聚合对象的职责。
    ③ 单例模式
    将创建对象与管理单例分别封装在两个方法中,两个方法相互独立互不影响。
    ④ 装饰者模式
    让类或者对象一开始只具有一些基础的职责,更多的职责在代码运行时被动态装饰到对象上面。装饰者模式可以为对象动态增加职责,从另一个角度来看, 这也是分离职责的一种方式。
  4. 应用场景
    ① 如果有两个职责总是同时变化,那就不必分离他们。即使两个职责已经被耦合在一起,但它们还没有发生改变的征兆,那么也许没有必要主动分离它们。
    ② 在方便性与稳定性之间要有一些取舍。具体是选择方便性还是稳定性,并没有标准答案,而是要取决于具体的应用环境。例如:jQueryattr 是个非常庞大的方法,既负责赋值,又负责取值,这对于jQuery的维护者来说,会带来一些困难,但对于jQuery的用户来说,却简化了用户的使用。
  5. 优缺点
    ① 优点
    按照职责把对象分解成更小的粒度,降低了单个类或者对象的复杂度,有助于代码的复用,也有利于进行单元测试。
    ② 缺点
    增加了编写代码的复杂度,也增大了这些对象之间相互联系的难度。

3 最少知识原则

  1. 简介
    最少知识原则(LKP)指一个软件实体应当尽可能少地与其他实体发生相互作用。这里的软件实体不仅包括对象,还包括系统、类、模块、函数、变量等。
  2. 减少对象之间的联系
    单一职责原则指导我们把对象划分成较小的粒度,提高对象的可复用性。但越来越多的对象之间可能会产生错综复杂的联系,如果修改了其中一个对象,很可能会影响到跟它相互引用的其他对象。
    最少知识原则要求我们尽量减少对象之间的交互。如果两个对象之间不必彼此直接通信,那么这两个对象就不要发生直接的相互联系。
  3. 设计模式验证
    ① 中介者模式
    增加一个中介者对象,让所有的相关对象都通过中介者对象来通信,而不是互相引用。当一个对象发生改变时,只需要通知中介者对象即可。
    ② 外观模式
    外观模式对客户提供一个简单易用的高层接口,高层接口会把客户的请求转发给子系统来完成具体的功能实现。

4 开放-封闭原则

  1. 简介
    软件实体(类、模块、函数)等应该是可以扩展的,但是不可修改。
  2. 原则
    当需要改变一个程序的功能或者给这个程序增加新功能的时候,可以使用增加代码的方式,但是不允许改动程序的源代码。
  3. 实现方式
    通过封装变化的方式,可以把系统中稳定不变的部分和容易变化的部分隔离开来。
    (1) 利用对象多态性
    利用对象的多态性来消除条件分支语句。
    (2) 放置挂钩
    在程序有可能发生变化的地方放置一个挂钩,挂钩的返回结果决定了程序的下一步走向。
    (3) 回调函数
    把一部分易于变化的逻辑封装在回调函数里,然后把回调函数当作参数传入一个稳定和封闭的函数中。
  4. 设计模式验证
    ① 观察者模式
    当有新的订阅者出现时,发布者的代码不需要进行任何修改;同样当发布者需要改变时,也不会影响到之前的订阅者。
    ② 模板方法模式
    子类的方法种类和执行顺序都是不变的,所以我们把这部分逻辑抽出来放到父类的模板方法里面;而子类的方法具体怎么实现则是可变的,于是把这部分变化的逻辑封装到子类中。通过增加新的子类,便能给系统增加新的功能,并不需要改动抽象父类以及其他的子类。
    ③ 策略模式
    策略模式将各种算法都封装成单独的策略类,这些策略类可以被交换使用。策略和使用策略的客户代码可以分别独立进行修改而互不影响。
    ④ 代理模式
    图片预加载示例中,代理函数proxyMyImage负责图片预加载,myImage图片加载函数不需要任何改动。
    ⑤ 职责链模式
    新增处理函数时,不需要改动原有的链条节点代码,只需要在链条中增加一个新的节点。

5 代码重构

  1. 提炼函数
    如果在函数中有一段代码可以被独立出来,那我们最好把这些代码放进另外一个独立的函数中。
var getUserInfo = function () {
  ajax('http:// xxx.com/userInfo', function (data) {
    console.log('userId: ' + data.userId);
    console.log('userName: ' + data.userName);
    console.log('nickName: ' + data.nickName);
  })
}

//改成
var getUserInfo = function () {
  ajax('http:// xxx.com/userInfo', function (data) {
    printDetails(data);
  });
};
var printDetails = function (data) {
  console.log('userId: ' + data.userId);
  console.log('userName: ' + data.userName);
  console.log('nickName: ' + data.nickName);
};
  1. 合并重复的条件片段
    如果一个函数体内有一些条件分支语句,而这些条件分支语句内部散布了一些重复的代码,那么就有必要进行合并去重工作。
var paging = function (currPage) {
  if (currPage <= 0) {
    currPage = 0;
    jump(currPage); // 跳转 
  } else if (currPage >= totalPage) {
    currPage = totalPage;
    jump(currPage);
  } else {
    jump(currPage);
  }
};

//改成
var paging = function (currPage) {
  if (currPage <= 0) {
    currPage = 0;
  } else if (currPage >= totalPage) {
    currPage = totalPage;
  }
  jump(currPage); // 把 jump 函数独立出来 
};
  1. 把条件分支语句提炼成函数
    在程序设计中,复杂的条件分支语句是导致程序难以阅读和理解的重要原因,而且容易导致一个庞大的函数。
var getPrice = function (price) {
  var date = new Date();
  if (date.getMonth() >= 6 && date.getMonth() <= 9) {
    return price * 0.8;
  }
  return price;
};

//改成
var isSummer = function () {
  var date = new Date();
  return date.getMonth() >= 6 && date.getMonth() <= 9;
};
var getPrice = function (price) {
  if (isSummer()) { // 夏天
    return price * 0.8;
  }
  return price;
};
  1. 合理使用循环
    在函数体内,如果有些代码实际上负责的是一些重复性的工作,那么合理利用循环不仅可以完成同样的功能,还可以使代码量更少。
var createXHR = function () {
  var xhr;
  try {
    xhr = new ActiveXObject('MSXML2.XMLHttp.6.0');
  } catch (e) {
    try {
      xhr = new ActiveXObject('MSXML2.XMLHttp.3.0');
    } catch (e) {
      xhr = new ActiveXObject('MSXML2.XMLHttp');
    }
  }
  return xhr;
};
var xhr = createXHR();

//改成
var createXHR = function () {
  var versions = ['MSXML2.XMLHttp.6.0ddd', 'MSXML2.XMLHttp.3.0', 'MSXML2.XMLHttp'];
  for (var i = 0, version; version = versions[i++];) {
    try {
      return new ActiveXObject(version);
    } catch (e) {
    }
  }
};
var xhr = createXHR();
  1. 提前让函数退出代替嵌套条件分支
    嵌套的条件分支语句绝对是代码维护者的噩梦。嵌套的条件分支往往是由一些深信“每个函数只能有一个出口的”程序员写出的。但实际上,如果对函数的剩余部分不感兴趣,那就应该立即退出。
var del = function (obj) {
  var ret;
  if (!obj.isReadOnly) { // 不为只读的才能被删除
    if (obj.isFolder) { // 如果是文件夹
      ret = deleteFolder(obj);
    } else if (obj.isFile) {
      ret = deleteFile(obj);
    }
  }
  return ret;
};

var del = function (obj) {
  if (obj.isReadOnly) {
    return;
  }
  if (obj.isFolder) {
    return deleteFolder(obj);
  }
  if (obj.isFile) {
    return deleteFile(obj);
  }
};
  1. 传递对象参数代替过长的参数列表
    有时候一个函数有可能接收多个参数,而参数的数量越多,函数就越难理解和使用。在使用的时候,还要小心翼翼,以免少传了某个参数或者把两个参数搞反了位置。
    这时我们可以把参数都放入一个对象内,不用再关心参数的数量和顺序,只要保证参数对应的 key 值不变就可以了。
  2. 尽量减少参数数量
    在实际开发中,向函数传递参数不可避免,但我们应该尽量减少函数接收的参数数量。
  3. 少用三目运算符
    如果条件分支逻辑简单且清晰,这无碍我们使用三目运算符;但如果条件分支逻辑非常复杂,我们最好的选择还是按部就班地编写 if...else...
  4. 合理使用链式调用
    经常使用jQuery的程序员相当习惯链式调用方法,在JavaScript 中,可以很容易地实现方法的链式调用,即让方法调用结束后返回对象自身。
    使用链式调用的方式可以省下一些字符和中间变量,但调试时不方便。如果我们知道一条链中有错误出现,必须得先把这条链拆开才能加上一些调试log或者增加断点。
    如果该链条的结构相对稳定,后期不易发生修改,可以使用链式调用。如果该链条很容易发生变化,导致调试和维护困难,那么还是建议使用普通调用的形式。
  5. 分解大型类
    面向对象设计鼓励将行为分布在合理数量的更小对象之中。
  6. return退出多重循环
    假设在函数体内有一个两重循环语句,我们需要在内层循环中判断,当达到某个临界条件时退出外层的循环。我们大多数时候会引入一个控制标记变量或设置循环标记。
    这两种做法无疑都让人头晕目眩,更简单的做法是在需要中止循环的时候直接退出整个方法。
    如果在循环之后还有一些将被执行的代码,我们可以把循环后面的代码放到 return 后面,如果代码比较多,就应该把它们提炼成一个单独的函数。

参考资料

  • 《JavaScript设计模式与开发实践》(曾探)