SOLID

单一职责原则 (SRP)

正如代码整洁之道所述， “永远不要有超过一个理由来修改一个类”。 给一个类塞满许多功能， 就像你在航
班上只能带一个行李箱一样， 这样做的问题你的类不会有理想的内聚性， 将会有太多的理由来对它进行修改。
最小化需要修改一个类的次数时很重要的， 因为如果一个类拥有太多的功能， 一旦你修改它的一小部分，
将会很难弄清楚会对代码库中的其它模块造成什么影响。

不好的：

  1. class UserSettings {
  2.   constructor(user) {
  3.     this.user = user;
  4.   }
  6.   changeSettings(settings) {
  7.     if (this.verifyCredentials()) {
  8.       // ...
  9.     }
  10.   }
  12.   verifyCredentials() {
  13.     // ...
  14.   }
  15. }

好的：

  1. class UserAuth {
  2.   constructor(user) {
  3.     this.user = user;
  4.   }
  6.   verifyCredentials() {
  7.     // ...
  8.   }
  9. }
  12. class UserSettings {
  13.   constructor(user) {
  14.     this.user = user;
  15.     this.auth = new UserAuth(user);
  16.   }
  18.   changeSettings(settings) {
  19.     if (this.auth.verifyCredentials()) {
  20.       // ...
  21.     }
  22.   }
  23. }

开闭原则 (OCP)

Bertrand Meyer 说过， “软件实体 (类， 模块， 函数等) 应该为扩展开放， 但是为修改关闭。” 这
是什么意思呢？ 这个原则基本上说明了你应该允许用户添加功能而不必修改现有的代码。

不好的：

  1. class AjaxAdapter extends Adapter {
  2.   constructor() {
  3.     super();
  4.     this.name = 'ajaxAdapter';
  5.   }
  6. }
  8. class NodeAdapter extends Adapter {
  9.   constructor() {
  10.     super();
  11.     this.name = 'nodeAdapter';
  12.   }
  13. }
  15. class HttpRequester {
  16.   constructor(adapter) {
  17.     this.adapter = adapter;
  18.   }
  20.   fetch(url) {
  21.     if (this.adapter.name === 'ajaxAdapter') {
  22.       return makeAjaxCall(url).then((response) => {
  23.         // transform response and return
  24.       });
  25.     } else if (this.adapter.name === 'httpNodeAdapter') {
  26.       return makeHttpCall(url).then((response) => {
  27.         // transform response and return
  28.       });
  29.     }
  30.   }
  31. }
  33. function makeAjaxCall(url) {
  34.   // request and return promise
  35. }
  37. function makeHttpCall(url) {
  38.   // request and return promise
  39. }

好的：

  1. class AjaxAdapter extends Adapter {
  2.   constructor() {
  3.     super();
  4.     this.name = 'ajaxAdapter';
  5.   }
  7.   request(url) {
  8.     // request and return promise
  9.   }
  10. }
  12. class NodeAdapter extends Adapter {
  13.   constructor() {
  14.     super();
  15.     this.name = 'nodeAdapter';
  16.   }
  18.   request(url) {
  19.     // request and return promise
  20.   }
  21. }
  23. class HttpRequester {
  24.   constructor(adapter) {
  25.     this.adapter = adapter;
  26.   }
  28.   fetch(url) {
  29.     return this.adapter.request(url).then((response) => {
  30.       // transform response and return
  31.     });
  32.   }
  33. }

里氏代换原则 (LSP)

这是针对一个非常简单的里面的一个恐怖意图， 它的正式定义是： “如果 S 是 T 的一个子类型， 那么类
型为 T 的对象可以被类型为 S 的对象替换（例如， 类型为 S 的对象可作为类型为 T 的替代品）儿不需
要修改目标程序的期望性质 （正确性、 任务执行性等）。” 这甚至是个恐怖的定义。

最好的解释是， 如果你又一个基类和一个子类， 那个基类和字类可以互换而不会产生不正确的结果。 这可
能还有有些疑惑， 让我们来看一下这个经典的正方形与矩形的例子。 从数学上说， 一个正方形是一个矩形，
但是你用 “is-a” 的关系用继承来实现， 你将很快遇到麻烦。

不好的：

  1. class Rectangle {
  2.   constructor() {
  3.     this.width = 0;
  4.     this.height = 0;
  5.   }
  7.   setColor(color) {
  8.     // ...
  9.   }
  11.   render(area) {
  12.     // ...
  13.   }
  15.   setWidth(width) {
  16.     this.width = width;
  17.   }
  19.   setHeight(height) {
  20.     this.height = height;
  21.   }
  23.   getArea() {
  24.     return this.width * this.height;
  25.   }
  26. }
  28. class Square extends Rectangle {
  29.   setWidth(width) {
  30.     this.width = width;
  31.     this.height = width;
  32.   }
  34.   setHeight(height) {
  35.     this.width = height;
  36.     this.height = height;
  37.   }
  38. }
  40. function renderLargeRectangles(rectangles) {
  41.   rectangles.forEach((rectangle) => {
  42.     rectangle.setWidth(4);
  43.     rectangle.setHeight(5);
  44.     const area = rectangle.getArea(); // BAD: Will return 25 for Square. Should be 20.
  45.     rectangle.render(area);
  46.   });
  47. }
  49. const rectangles = [new Rectangle(), new Rectangle(), new Square()];
  50. renderLargeRectangles(rectangles);

好的：

  1. class Shape {
  2.   setColor(color) {
  3.     // ...
  4.   }
  6.   render(area) {
  7.     // ...
  8.   }
  9. }
  11. class Rectangle extends Shape {
  12.   constructor(width, height) {
  13.     super();
  14.     this.width = width;
  15.     this.height = height;
  16.   }
  18.   getArea() {
  19.     return this.width * this.height;
  20.   }
  21. }
  23. class Square extends Shape {
  24.   constructor(length) {
  25.     super();
  26.     this.length = length;
  27.   }
  29.   getArea() {
  30.     return this.length * this.length;
  31.   }
  32. }
  34. function renderLargeShapes(shapes) {
  35.   shapes.forEach((shape) => {
  36.     const area = shape.getArea();
  37.     shape.render(area);
  38.   });
  39. }
  41. const shapes = [new Rectangle(4, 5), new Rectangle(4, 5), new Square(5)];
  42. renderLargeShapes(shapes);

接口隔离原则 (ISP)

JavaScript 没有接口， 所以这个原则不想其它语言那么严格。 不过， 对于 JavaScript 这种缺少类
型的语言来说， 它依然是重要并且有意义的。

接口隔离原则说的是 “客户端不应该强制依赖他们不需要的接口。” 在 JavaScript 这种弱类型语言中，
接口是隐式的契约。

在 JavaScript 中能比较好的说明这个原则的是一个类需要一个巨大的配置对象。 不需要客户端去设置大
量的选项是有益的， 因为多数情况下他们不需要全部的设置。 让它们变成可选的有助于防止出现一个“胖接
口”。

不好的：

  1. class DOMTraverser {
  2.   constructor(settings) {
  3.     this.settings = settings;
  4.     this.setup();
  5.   }
  7.   setup() {
  8.     this.rootNode = this.settings.rootNode;
  9.     this.animationModule.setup();
  10.   }
  12.   traverse() {
  13.     // ...
  14.   }
  15. }
  17. const $ = new DOMTraverser({
  18.   rootNode: document.getElementsByTagName('body'),
  19.   animationModule() {} // Most of the time, we won't need to animate when traversing.
  20.   // ...
  21. });

好的：

  1. class DOMTraverser {
  2.   constructor(settings) {
  3.     this.settings = settings;
  4.     this.options = settings.options;
  5.     this.setup();
  6.   }
  8.   setup() {
  9.     this.rootNode = this.settings.rootNode;
  10.     this.setupOptions();
  11.   }
  13.   setupOptions() {
  14.     if (this.options.animationModule) {
  15.       // ...
  16.     }
  17.   }
  19.   traverse() {
  20.     // ...
  21.   }
  22. }
  24. const $ = new DOMTraverser({
  25.   rootNode: document.getElementsByTagName('body'),
  26.   options: {
  27.     animationModule() {}
  28.   }
  29. });

依赖反转原则 (DIP)

这个原则阐述了两个重要的事情：

  1. 高级模块不应该依赖于低级模块， 两者都应该依赖与抽象；
  2. 抽象不应当依赖于具体实现， 具体实现应当依赖于抽象。

这个一开始会很难理解， 但是如果你使用过 Angular.js ， 你应该已经看到过通过依赖注入来实现的这
个原则， 虽然他们不是相同的概念， 依赖反转原则让高级模块远离低级模块的细节和创建， 可以通过 DI
来实现。 这样做的巨大益处是降低模块间的耦合。 耦合是一个非常糟糕的开发模式， 因为会导致代码难于
重构。

如上所述， JavaScript 没有接口， 所以被依赖的抽象是隐式契约。 也就是说， 一个对象/类的方法和
属性直接暴露给另外一个对象/类。 在下面的例子中， 任何一个 Request 模块的隐式契约 InventoryTracker
将有一个 requestItems 方法。

不好的：

  1. class InventoryRequester {
  2.   constructor() {
  3.     this.REQ_METHODS = ['HTTP'];
  4.   }
  6.   requestItem(item) {
  7.     // ...
  8.   }
  9. }
  11. class InventoryTracker {
  12.   constructor(items) {
  13.     this.items = items;
  15.     // 不好的： 我们已经创建了一个对请求的具体实现的依赖， 我们只有一个 requestItems 方法依
  16.     // 赖一个请求方法 'request'
  17.     this.requester = new InventoryRequester();
  18.   }
  20.   requestItems() {
  21.     this.items.forEach((item) => {
  22.       this.requester.requestItem(item);
  23.     });
  24.   }
  25. }
  27. const inventoryTracker = new InventoryTracker(['apples', 'bananas']);
  28. inventoryTracker.requestItems();

好的：

  1. class InventoryTracker {
  2.   constructor(items, requester) {
  3.     this.items = items;
  4.     this.requester = requester;
  5.   }
  7.   requestItems() {
  8.     this.items.forEach((item) => {
  9.       this.requester.requestItem(item);
  10.     });
  11.   }
  12. }
  14. class InventoryRequesterV1 {
  15.   constructor() {
  16.     this.REQ_METHODS = ['HTTP'];
  17.   }
  19.   requestItem(item) {
  20.     // ...
  21.   }
  22. }
  24. class InventoryRequesterV2 {
  25.   constructor() {
  26.     this.REQ_METHODS = ['WS'];
  27.   }
  29.   requestItem(item) {
  30.     // ...
  31.   }
  32. }
  34. // 通过外部创建依赖项并将它们注入， 我们可以轻松的用一个崭新的使用 WebSockets 的请求模块进行
  35. // 替换。
  36. const inventoryTracker = new InventoryTracker(['apples', 'bananas'], new InventoryRequesterV2());
  37. inventoryTracker.requestItems();