1 设计原则概述
- 《
UNIX/LINUX设计哲学》设计准则 ① 小既是美。 ② 每个程序只做一件事情。 ③ 快速建立原型。 ④ 舍弃高效率而取可移植性。 ⑤ 避免强制性的图形化界面交互。 ⑥ 让每个程序都成为过滤器。 ⑦ 寻求90%的解决方案。 注释：花20%的成本解决80%的需求。 - 五大设计原则(
SOLID) ① S - 单一职责原则 ② O - 开放封闭原则 ③ L - 李氏置换原则 ④ I - 接口独立原则 ⑤ D - 依赖倒置原则 - 单一职责原则 一个程序只做好一件事情。
- 开放封闭原则 对扩展开放，对修改封闭。 增加需求时，扩展新代码，而非修改已有代码。
- 李氏置换原则 子类能覆盖父类。 父类能出现的地方子类就能出现。
- 接口独立原则 保持接口的独立，避免出现“胖接口”。
- 依赖倒置原则 面向接口编程，依赖于抽象而不依赖于具体。
2 单一职责原则
- 简介 就一个类、对象以及方法而言，应该仅有一个引起它变化的原因。 注释：单一职责原则定义为“引起变化的原因”。如果我们有两个动机去改写一个方法，那么这个方法就具有两个职责。
- 原则 一个对象(方法)只做一件事情。
- 设计模式验证 ① 代理模式 图片预加载代理模式中，代理对象负责预加载职责，本体对象负责图片加载职责。 ② 迭代器模式 迭代器模式提供遍历访问聚合对象的职责。 ③ 单例模式 将创建对象与管理单例分别封装在两个方法中，两个方法相互独立互不影响。 ④ 装饰者模式 让类或者对象一开始只具有一些基础的职责，更多的职责在代码运行时被动态装饰到对象上面。装饰者模式可以为对象动态增加职责，从另一个角度来看， 这也是分离职责的一种方式。
- 应用场景 ① 如果有两个职责总是同时变化，那就不必分离他们。即使两个职责已经被耦合在一起，但它们还没有发生改变的征兆，那么也许没有必要主动分离它们。 ② 在方便性与稳定性之间要有一些取舍。具体是选择方便性还是稳定性，并没有标准答案，而是要取决于具体的应用环境。例如：
jQuery的 attr 是个非常庞大的方法，既负责赋值，又负责取值，这对于jQuery的维护者来说，会带来一些困难，但对于jQuery的用户来说，却简化了用户的使用。 - 优缺点 ① 优点 按照职责把对象分解成更小的粒度，降低了单个类或者对象的复杂度，有助于代码的复用，也有利于进行单元测试。 ② 缺点 增加了编写代码的复杂度，也增大了这些对象之间相互联系的难度。
3 最少知识原则
- 简介 最少知识原则(
LKP)指一个软件实体应当尽可能少地与其他实体发生相互作用。这里的软件实体不仅包括对象，还包括系统、类、模块、函数、变量等。 - 减少对象之间的联系 单一职责原则指导我们把对象划分成较小的粒度，提高对象的可复用性。但越来越多的对象之间可能会产生错综复杂的联系，如果修改了其中一个对象，很可能会影响到跟它相互引用的其他对象。 最少知识原则要求我们尽量减少对象之间的交互。如果两个对象之间不必彼此直接通信，那么这两个对象就不要发生直接的相互联系。
- 设计模式验证 ① 中介者模式 增加一个中介者对象，让所有的相关对象都通过中介者对象来通信，而不是互相引用。当一个对象发生改变时，只需要通知中介者对象即可。 ② 外观模式 外观模式对客户提供一个简单易用的高层接口，高层接口会把客户的请求转发给子系统来完成具体的功能实现。
4 开放-封闭原则
- 简介 软件实体(类、模块、函数)等应该是可以扩展的，但是不可修改。
- 原则 当需要改变一个程序的功能或者给这个程序增加新功能的时候，可以使用增加代码的方式，但是不允许改动程序的源代码。
- 实现方式 通过封装变化的方式，可以把系统中稳定不变的部分和容易变化的部分隔离开来。 (1) 利用对象多态性 利用对象的多态性来消除条件分支语句。 (2) 放置挂钩 在程序有可能发生变化的地方放置一个挂钩，挂钩的返回结果决定了程序的下一步走向。 (3) 回调函数 把一部分易于变化的逻辑封装在回调函数里，然后把回调函数当作参数传入一个稳定和封闭的函数中。
- 设计模式验证 ① 观察者模式 当有新的订阅者出现时，发布者的代码不需要进行任何修改；同样当发布者需要改变时，也不会影响到之前的订阅者。 ② 模板方法模式 子类的方法种类和执行顺序都是不变的，所以我们把这部分逻辑抽出来放到父类的模板方法里面；而子类的方法具体怎么实现则是可变的，于是把这部分变化的逻辑封装到子类中。通过增加新的子类，便能给系统增加新的功能，并不需要改动抽象父类以及其他的子类。 ③ 策略模式 策略模式将各种算法都封装成单独的策略类，这些策略类可以被交换使用。策略和使用策略的客户代码可以分别独立进行修改而互不影响。 ④ 代理模式 图片预加载示例中，代理函数
proxyMyImage负责图片预加载，myImage图片加载函数不需要任何改动。 ⑤ 职责链模式 新增处理函数时，不需要改动原有的链条节点代码，只需要在链条中增加一个新的节点。
5 代码重构
- 提炼函数 如果在函数中有一段代码可以被独立出来，那我们最好把这些代码放进另外一个独立的函数中。
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); }; - 合并重复的条件片段 如果一个函数体内有一些条件分支语句，而这些条件分支语句内部散布了一些重复的代码，那么就有必要进行合并去重工作。
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 函数独立出来 }; - 把条件分支语句提炼成函数 在程序设计中，复杂的条件分支语句是导致程序难以阅读和理解的重要原因，而且容易导致一个庞大的函数。
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; }; - 合理使用循环 在函数体内，如果有些代码实际上负责的是一些重复性的工作，那么合理利用循环不仅可以完成同样的功能，还可以使代码量更少。
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(); - 提前让函数退出代替嵌套条件分支 嵌套的条件分支语句绝对是代码维护者的噩梦。嵌套的条件分支往往是由一些深信“每个函数只能有一个出口的”程序员写出的。但实际上，如果对函数的剩余部分不感兴趣，那就应该立即退出。
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); } }; - 传递对象参数代替过长的参数列表 有时候一个函数有可能接收多个参数，而参数的数量越多，函数就越难理解和使用。在使用的时候，还要小心翼翼，以免少传了某个参数或者把两个参数搞反了位置。 这时我们可以把参数都放入一个对象内，不用再关心参数的数量和顺序，只要保证参数对应的
key 值不变就可以了。 - 尽量减少参数数量 在实际开发中，向函数传递参数不可避免，但我们应该尽量减少函数接收的参数数量。
- 少用三目运算符 如果条件分支逻辑简单且清晰，这无碍我们使用三目运算符；但如果条件分支逻辑非常复杂，我们最好的选择还是按部就班地编写
if...else...。 - 合理使用链式调用 经常使用
jQuery的程序员相当习惯链式调用方法，在JavaScript 中，可以很容易地实现方法的链式调用，即让方法调用结束后返回对象自身。 使用链式调用的方式可以省下一些字符和中间变量，但调试时不方便。如果我们知道一条链中有错误出现，必须得先把这条链拆开才能加上一些调试log或者增加断点。 如果该链条的结构相对稳定，后期不易发生修改，可以使用链式调用。如果该链条很容易发生变化，导致调试和维护困难，那么还是建议使用普通调用的形式。 - 分解大型类 面向对象设计鼓励将行为分布在合理数量的更小对象之中。
- 用
return退出多重循环 假设在函数体内有一个两重循环语句，我们需要在内层循环中判断，当达到某个临界条件时退出外层的循环。我们大多数时候会引入一个控制标记变量或设置循环标记。 这两种做法无疑都让人头晕目眩，更简单的做法是在需要中止循环的时候直接退出整个方法。 如果在循环之后还有一些将被执行的代码，我们可以把循环后面的代码放到 return 后面，如果代码比较多，就应该把它们提炼成一个单独的函数。