JavaScript设计模式之设计原则

何为设计

即按照哪一种思路或者标准来实现功能，功能相同，可以有不同的设计方案来实现

伴随着需求的增加，设计的作用就会体现出来，一般的APP每天都在变化，更新很快，需求不断在增加，如果设计的不好，后面很难维护

结合《UNIX/LINUX设计哲学》10大设计准责

小即是美

相对于同类庞然大物，小巧的事物有着其无可比拟的巨大优势。其中一点就是它们能够以独特有效的方式结合其他小事务，而且这种方式往往是最初的设计者没能预见的。

让每一个程序只做好一件事情

通过集中精力应对单一任务，程序可以减少冗余代码，从而避免过高的开销、不必要的复杂性和缺乏灵活性。

尽快建立原型

大多数人认同“建立原型是任何项目的一个重要组成部分。在其他方法论中，建立原型只是设计中一个不太重要的组成部分，然而，在Unix环境下它却是达成完美设计的主要工具。

舍高效率而取可移植性

当Unix作为第一个可移植系统而开创先河时，它曾经掀起过轩然大波。今天，可移植性早被视作现代软件设计中一个理所当然的特性，这更加充分说明这条Unix准则早就在Unix之外的系统中获得了广泛认可

使用纯文本文件来存储数据

舍高效率而取可移植性强调了可移植代码的重要性。其实可移植性数据的重要性绝不亚于可移植代码。在关于可移植性的准则中，人们往往容易忽视可移植性数据。 

充分利用软件的杠杆效应

很多程序员对可重用代码模块的重要性只有一些肤浅认识。代码重用能帮助人们充分利用软件的杠杆效应。一些Unix的开发人员正是遵循这个强大的理念，在相对较短的时间内编写出了大量应用程序。

使用shell脚本来提高杠杆效应和可移植性

shell脚本在软件设计中可谓是一把双刃剑，它可以加强软件的可重用性和可移植性。无论什么时候，只要有可能，编写shell脚本来替代C语言程序都不失为一个良好的选择。

避免强制性的用户界面

Unix开发人员非常了解，有一些命令用户界面为什么会被称为是“强制性的"用户界面。这些命令在运行的时候会阻止用户去运行其他命令，这样用户就会成为这些系统的囚徒。在图形用户界面中，这样的界面被称为”模态“。

让每一个程序都成为过滤器

所有软件程序共有的最基本特性就是，它们只是修改而从不创造数据。因此，基于软件的过滤器本质，人们就应该把它们编写成执行过滤器任务的程序。

 

下面还列出了10条次要准则，这些准则正在渐渐发展成Unix世界信奉体系的一个组成部分。并非每个与Unix打交道的人都会将它们奉为信条，而且在严格意义上其中一些不能算作是Unix的特性。不过，它们看起来依然是Unix文化（当然地也包括Linux文化）不可或缺的一部分。

允许用户定制环境

Unix用户喜欢掌控系统环境，并且是整个环境。很多Unix应用程序绝对不会一刀切地使用交互风格，而是将选择的权利交给用户。它的基本思想就是，程序应该只是提供解决问题的机制，而不是为解决问题的方法限定标准。让用户探索属于自己的通往计算机的家境之路吧。

尽量使操作系统内核小而轻巧

尽管对新功能的追求永无止境，Unix开发人员还是喜欢让操作系统最核心部分保持最小的规模。当然，他们并不总是能做到这一点，但这是他们的目标。

使用小写字母，并尽量保持简短

使用小写字母是Unix环境中的传统，尽管这么做的理由已不复存在，但人们还是保留了这个传统。今天，许多Unix用户之所以要使用小写的命令和神秘的名字，不再是因为有其限制条件，而是他们就喜欢这么做。

保护树木

Unix用户普遍不太赞成使用纸质文档。而是在线存储所有文字档案。此外，使用功能强大的在线工具来处理文件是非常环保的做法。

沉默是金

在需要提供出错信息的时候，Unix命令是出了名的喜欢保持沉默。虽然很多经验丰富的Unix用户认为这是可取得做法，可其他操作系统的用户却并不赞同这种观点。

并行思考

大多数任务都能分解成更小的子任务。这些子任务可以并行运行，因而，在完成一项大任务的时间内，可以完成更多子任务。今天已涌现出大量对称处理（symmetric multiprocessing，SMP）设计，这说明计算机行业正朝着并行处理的方向发展。

各部分之和大于整体

小程序集合而成的大型应用程序比单个的大程序更灵活，也更为实用，本条准则正式源于此想法。两种解决方案可能具备同样的功能，可集合小程序的做法更具有前瞻性。

寻找90%的解决方案

百分百的完成任何事情都是很困难的。完成90%的目标会更有效率，并且更节省成本。Unix开发人员总是在寻找能够满足目标用户90%要求的解决方案，剩下的10%则任其自生自灭。

更坏就是更好

Unix爱好者认为具有”最小公分母“的系统是最容易存活的系统。比起高品质而昂贵的系统，那些便宜但有效的系统更容易得到普及。于是，PC兼容机的世界从Unix世界借鉴了此想法，并取得了巨大成功。这其中的关键字就是包容。如果某一事物的包容性强到足以涵盖几乎所有事物，那它就比那些”独家”系统要好得多。

层次化思考

Unix用户和开发人员都喜欢层次来组织事物。例如，Unix目录结构是最早将树结构应用于文件系统的架构之一。Unix的层次化思考已扩展到其他领域，如网络服务命名器、窗口管理、面向对象开发。

 

 

 

 

 

SOLID 五大设计原则

单一职责原则（The Single-Responsibility Principle (SRP)）

单一职责有2个含义，一个是避免相同的职责分散到不同的类中,另一个是避免一个类承担太多职责。减少类的耦合，提高类的复用性。

一个程序只做好一件事情，如果功能过于复杂就拆分开，每个部分保持独立

开放封闭原则（The Open/Closed Principle (OCP)）

对扩展开发，对修改封闭，就是说增加新的需求的时候，扩展新的代码，而非修改已经有的代码

里氏替换原则 The Liskov Substitution Principle (LSP)

子类型必须能够替换掉他们的父类型、并出现在父类能够出现的任何地方。主要针对继承的设计原则

父类的方法都要在子类中实现或者重写，并且派生类只实现其抽象类中生命的方法，而不应当给出多余的,方法定义或实现。

在客户端程序中只应该使用父类对象而不应当直接使用子类对象，这样可以实现运行期间绑定。

接口分离原则 The Interface Segregation Principle (ISP)

表明客户端不应该被强迫实现一些他们不会使用的接口，应该把胖接口中额方法分组，然后用多个接口代替它，每个接口服务于一个子模块。简单说，就是使用多个专门的接口比使用单个接口好很多。

依赖倒置原则 The Dependency-Inversion Principle (DIP)

上层模块不应该依赖于下层模块，他们共同依赖于一个抽象(父类不能依赖子类，他们都要依赖抽象类)。抽象不能依赖于具体，具体应该要依赖于抽象。

接下使用promise来演示一下单一职责原则和开放封闭原则（因为这两种在开发种体现的比较多）

function loadImg(src) {
  let promise = new Promise(function (resolve, reject) {
    let img = document.createElement('img')
    img.onload = function () {
      resolve(img)
    }
    img.onerror = function () {
      reject('图片加载失败')
    }
    img.src = src
  })
  return promise
}

let src = 'https://pics6.baidu.com/feed/0b46f21fbe096b635d43b3e50b6b3b40eaf8ac8e.jpeg'
let result = loadImg(src)

result.then(function (img) {
  console.log('img.width', img.width)
  return img
}).then(function (img) {
  console.log('img.height', img.height)
}).catch(function (ex) {
  console.log(ex) // 统一捕获异常
})

单一职责原则：每个then种的逻辑只做一件事情

开放封闭原则：如果新增需求，扩展then（promise对象种可以不断添加then的回调函数）

 

 

 

从设计到模式

何为设计模式，可以拆分开两个词来理解，设计是一种思想，而模式是根据设计开发出来的模板

 

 

23种设计模式的介绍

23种设计模式种可以分为3类

创建型：工厂模式（工厂方法模式，抽象工厂模式，建造者模式），单例模式，原型模式

结构型：适配器模式，装饰器模式，代理模式，外观模式，桥接模式，组合模式，享元模式

行为型：策略模式，模板方法模式，观察者模式，迭代器模式，职责链模式，命令模式，备忘录模式，状态模式，访问者模式，中介者模式，解释器模式