认识达内从这里开始

我们在学习js开发编程语言的时候会学习到相关的js编程开发原则的相关知识，今天我们就通过案例分析来学习一下，应该如何在软件开发的过程中让我们的代码更加适应这些开发原则。

单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。在javascript中，需要用到类的场景并不太多，单一职责原则更多地是被运用在对象或者方法级别上

单一职责原则(SRP)的职责被定义为“引起变化的原因”。如果有两个动机去改写一个方法，那么这个方法就具有两个职责。每个职责都是变化的一个轴线，如果一个方法承担了过多的职责，那么在需求的变迁过程中，需要改写这个方法的可能性就越大。此时，这个方法通常是一个不稳定的方法，修改代码总是一件危险的事情，特别是当两个职责耦合在一起的时候，一个职责发生变化可能会影响到其他职责的实现，造成意想不到的破坏，这种耦合性得到的是低内聚和脆弱的设计。因此，SRP原则体现为：一个对象(方法)只做一件事情

SRP原则在很多设计模式中都有着广泛的运用，例如代理模式、迭代器模式、单例模式和装饰者模式

【代理模式】

通过增加虚拟代理的方式，把预加载图片的职责放到代理对象中，而本体仅仅负责往页面中添加img标签，这也是它最原始的职责

【迭代器模式】

有这样一段代码，先遍历一个集合，然后往页面中添加一些div，这些div的innerHTML分别对应集合里的元素：

【单例模式】

现在把管理单例的职责和创建登录浮窗的职责分别封装在两个方法里，这两个方法可以独立变化而互不影响，当它们连接在一起的时候，就完成了创建唯一登录浮窗的功能。

【装饰者模式】

使用装饰者模式时，通常让类或者对象一开始只具有一些基础的职责，更多的职责在代码运行时被动态装饰到对象上面。装饰者模式可以为对象动态增加职责，从另一个角度来看， 这也是分离职责的一种方式

SRP原则是所有原则中最简单也是最难正确运用的原则之一。要明确的是，并不是所有的职责都应该一一分离。一方面，如果随着需求的变化，有两个职责总是同时变化，那就不必分离他们。比如在ajax请求的时候，创建xhr对象和发送xhr请求几乎总是在一起的，那么创建xhr对象的职责和发送xhr请求的职责就没有必要分开。另一方面，职责的变化轴线仅当它们确定会发生变化时才具有意义，即使两个职责已经被耦合在一起，但它们还没有发生改变的征兆，那么也许没有必要主动分离它们，在代码需要重构的时候再进行分离也不迟

在人的常规思维中，总是习惯性地把一组相关的行为放到一起，如何正确地分离职责不是一件容易的事情。在实际开发中，因为种种原因违反SRP的情况并不少见。比如jQuery的attr等方法，就是明显违反SRP原则的做法。jQuery的attr是个非常庞大的方法，既负责赋值，又负责取值，这对于jQuery的维护者来说，会带来一些困难，但对于jQuery的用户来说，却简化了用户的使用。在方便性与稳定性之间要有一些取舍。具体是选择方便性还是稳定性，并没有标准答案，而是要取决于具体的应用环境

SRP原则的优点是降低了单个类或者对象的复杂度，按照职责把对象分解成更小的粒度，这有助于代码的复用，也有利于进行单元测试。当一个职责需要变更的时候，不会影响到其他的职责。但SRP原则也有一些缺点，最明显的是会增加编写代码的复杂度。当按照职责把对象分解成更小的粒度之后，实际上也增大了这些对象之间相互联系的难度

最少知识原则

最少知识原则(LKP)说的是一个软件实体应当尽可能少地与其他实体发生相互作用。这里的软件实体是一个广义的概念，不仅包括对象，还包括系统、类、模块、函数、变量等。

单一职责原则指导我们把对象划分成较小的粒度，这可以提高对象的可复用性。但越来越多的对象之间可能会产生错综复杂的联系，如果修改了其中一个对象，很可能会影响到跟它相互引用的其他对象。对象和对象耦合在一起，有可能会降低它们的可复用性。

最少知识原则要求我们在设计程序时，应当尽量减少对象之间的交互。如果两个对象之间不必彼此直接通信，那么这两个对象就不要发生直接的相互联系。常见的做法是引入一个第三者对象，来承担这些对象之间的通信作用。如果一些对象需要向另一些对象发起请求，可以通过第三者对象来转发这些请求

最少知识原则在设计模式中体现得最多的地方是中介者模式和外观模式

【中介者模式】

在世界杯期间购买足球彩票，如果没有博彩公司作为中介，上千万的人一起计算赔率和输赢绝对是不可能的事情。博彩公司作为中介，每个人都只和博彩公司发生关联，博彩公司会根据所有人的投注情况计算好赔率，彩民们赢了钱就从博彩公司拿，输了钱就赔给博彩公司。中介者模式很好地体现了最少知识原则。通过增加一个中介者对象，让所有的相关对象都通过中介者对象来通信，而不是互相引用。所以，当一个对象发生改变时，只需要通知中介者对象即可

【外观模式】

外观模式主要是为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使子系统更加容易使用

外观模式的作用是对客户屏蔽一组子系统的复杂性。外观模式对客户提供一个简单易用的高层接口，高层接口会把客户的请求转发给子系统来完成具体的功能实现。大多数客户都可以通过请求外观接口来达到访问子系统的目的。但在一段使用了外观模式的程序中，请求外观并不是强制的。如果外观不能满足客户的个性化需求，那么客户也可以选择越过外观来直接访问子系统

现在再来看看外观模式和最少知识原则之间的关系。外观模式的作用主要有两点

1、为一组子系统提供一个简单便利的访问入口

2、隔离客户与复杂子系统之间的联系，客户不用去了解子系统的细节。从第二点来，外观模式是符合最少知识原则的

封装在很大程度上表达的是数据的隐藏。一个模块或者对象可以将内部的数据或者实现细节隐藏起来，只暴露必要的接口API供外界访问。对象之间难免产生联系，当一个对象必须引用另外一个对象的时候，可以让对象只暴露必要的接口，让对象之间的联系限制在最小的范围之内。同时，封装也用来限制变量的作用域。

开放封闭原则

在面向对象的程序设计中，开放——封闭原则(OCP)是最重要的一条原则。很多时候，一个程序具有良好的设计，往往说明它是符合开放——封闭原则的。开放——封闭原则的定义如下：软件实体(类、模块、函数)等应该是可以扩展的，但是不可修改。

在项目需求变迁的过程中，经常会找到相关代码，然后改写它们。这似乎是理所当然的事情，不改动代码怎么满足新的需求呢?想要扩展一个模块，最常用的方式当然是修改它的源代码。如果一个模块不允许修改，那么它的行为常常是固定的。然而，改动代码是一种危险的行为，也许都遇到过bug越改越多的场景。刚刚改好了一个bug，但是又在不知不觉中引发了其他的bug

如果目前的window.onload函数是一个拥有500行代码的巨型函数，里面密布着各种变量和交叉的业务逻辑，而需求又不仅仅是打印一个log这么简单。那么“改好一个bug，引发其他bug”这样的事情就很可能会发生。永远不知道刚刚的改动会有什么副作用，很可能会引发一系列的连锁反应

通过动态装饰函数的方式，完全不用理会从前window.onload函数的内部实现，无论它的实现优雅或是丑陋。就算作为维护者，拿到的是一份混淆压缩过的代码也没有关系。只要它从前是个稳定运行的函数，那么以后也不会因为我们的新增需求而产生错误。新增的代码和原有的代码可以井水不犯河水

现在引出开放——封闭原则的思想：当需要改变一个程序的功能或者给这个程序增加新功能的时候，可以使用增加代码的方式，但是不允许改动程序的源代码

过多的条件分支语句是造成程序违反开放——封闭原则的一个常见原因。每当需要增加一个新的if语句时，都要被迫改动原函数。把if换成switch-case是没有用的，这是一种换汤不换药的做法。实际上，每当看到一大片的if或者swtich-case语句时，第一时间就应该考虑，能否利用对象的多态性来重构它们

利用对象的多态性来让程序遵守开放——封闭原则，是一个常用的技巧。下面先提供一段不符合开放——封闭原则的代码。每当增加一种新的动物时，都需要改动makeSound函数的内部实现。

遵守开放——封闭原则的规律，最明显的就是找出程序中将要发生变化的地方，然后把变化封装起来。通过封装变化的方式，可以把系统中稳定不变的部分和容易变化的部分隔离开来。在系统的演变过程中，只需要替换那些容易变化的部分，如果这些部分是已经被封装好的，那么替换起来也相对容易。而变化部分之外的就是稳定的部分。在系统的演变过程中，稳定的部分是不需要改变的

由于每种动物的叫声都不同，所以动物具体怎么叫是可变的，于是把动物具体怎么叫的逻辑从makeSound函数中分离出来。而动物都会叫这是不变的，makeSound函数里的实现逻辑只跟动物都会叫有关，这样一来，makeSound就成了一个稳定和封闭的函数。除了利用对象的多态性之外，还有其他方式可以帮助编写遵守开放——封闭原则的代码

【放置挂钩】

放置挂钩(hook)也是分离变化的一种方式。在程序有可能发生变化的地方放置一个挂钩，挂钩的返回结果决定了程序的下一步走向。这样一来，原本的代码执行路径上就出现了一个分叉路口，程序未来的执行方向被预埋下多种可能性。

由于子类的数量是无限制的，总会有一些“个性化”的子类迫使不得不去改变已经封装好的算法骨架。于是可以在父类中的某个容易变化的地方放置挂钩，挂钩的返回结果由具体子类决定。这样一来，程序就拥有了变化的可能

【使用回调函数】

在javascript中，函数可以作为参数传递给另外一个函数，这是高阶函数的意义之一。在这种情况下，通常会把这个函数称为回调函数。在javascript版本的设计模式中，策略模式和命令模式等都可以用回调函数轻松实现

回调函数是一种特殊的挂钩。可以把一部分易于变化的逻辑封装在回调函数里，然后把回调函数当作参数传入一个稳定和封闭的函数中。当回调函数被执行的时候，程序就可以因为回调函数的内部逻辑不同，而产生不同的结果

有一种说法是，设计模式就是给做的好的设计取个名字。几乎所有的设计模式都是遵守开放——封闭原则的。不管是具体的各种设计模式，还是更抽象的面向对象设计原则，比如单一职责原则、最少知识原则、依赖倒置原则等，都是为了让程序遵守开放——封闭原则而出现的。可以这样说，开放——封闭原则是编写一个好程序的目标，其他设计原则都是达到这个目标的过程。

【发布——订阅模式】

发布——订阅模式用来降低多个对象之间的依赖关系，它可以取代对象之间硬编码的通知机制，一个对象不用再显式地调用另外一个对象的某个接口。当有新的订阅者出现时，发布者的代码不需要进行任何修改;同样当发布者需要改变时，也不会影响到之前的订阅者

【模板方法模式】

模板方法模式是一种典型的通过封装变化来提高系统扩展性的设计模式。在一个运用了模板方法模式的程序中，子类的方法种类和执行顺序都是不变的，所以把这部分逻辑抽出来放到父类的模板方法里面;而子类的方法具体怎么实现则是可变的，于是把这部分变化的逻辑封装到子类中。通过增加新的子类，便能给系统增加新的功能，并不需要改动抽象父类以及其他的子类，这也是符合开放——封闭原则的

【策略模式】

策略模式和模板方法模式是一对竞争者。在大多数情况下，它们可以相互替换使用。模板方法模式基于继承的思想，而策略模式则偏重于组合和委托。策略模式将各种算法都封装成单独的策略类，这些策略类可以被交换使用。策略和使用策略的客户代码可以分别独立进行修改而互不影响。增加一个新的策略类也非常方便，完全不用修改之前的代码

【代理模式】

拿预加载图片举例，现在已有一个给图片设置src的函数myImage，想为它增加图片预加载功能时，一种做法是改动myImage函数内部的代码，更好的做法是提供一个代理函数proxyMyImage，代理函数负责图片预加载，在图片预加载完成之后，再将请求转交给原来的myImage函数，myImage在这个过程中不需要任何改动。预加载图片的功能和给图片设置src的功能被隔离在两个函数里，它们可以单独改变而互不影响。myImage不知晓代理的存在，它可以继续专注于自己的职责——给图片设置src

【职责链模式】

把一个巨大的订单函数分别拆成了500元订单、200元订单以及普通订单的3个函数。这3个函数通过职责链连接在一起，客户的请求会在这条链条里面依次传递。

在职责链模式代码中，开放——封闭原则要求只能通过增加源代码的方式扩展程序的功能，而不允许修改源代码。那往职责链中增加一个新的100元订单函数节点时，不也必须改动设置链条的代码吗?

实际上，让程序保持完全封闭是不容易做到的。就算技术上做得到，也需要花费太多的时间和精力。而且让程序符合开放——封闭原则的代价是引入更多的抽象层次，更多的抽象有可能会增大代码的复杂度。更何况，有一些代码是无论如何也不能完全封闭的，总会存在一些无法对其封闭的变化

作为程序员，可以做到的有下面两点

1、挑选出最容易发生变化的地方，然后构造抽象来封闭这些变化

2、在不可避免发生修改的时候，尽量修改那些相对容易修改的地方。拿一个开源库来说，修改它提供的配置文件，总比修改它的源代码来得简单。

作者：小火柴的蓝色理想

来源：博客园

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。