理解并应用JavaScript中的桥接模式
定义
桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。
应用场景
在封装开源库的组件时候，经常会用到这种设计模式。
例如，对外提供暴露一个complete函数,
如果用户有传入此函数, 那么就会在某一段代码逻辑中调用。
这个过程中，组件起到了“桥”的作用，而具体实现是用户自定义。
JavaScript 中桥接模式的典型应用是：Array对象上的forEach函数。
此函数负责循环遍历数组每个元素，是抽象部分；
而回调函数callback就是具体实现部分。
1、最简单模拟forEach方法：
let forEach = (arr, callbak) => {
if (Object.prototype.toString.call(callbak) != "[object Function]" || !Array.isArray(arr))
return;
for (let i = 0; i < arr.length; i++) {
callbak(arr[i], i);
}
}
let arr = [1, 2, 3];
forEach(arr, (v, i) => {
arr[i] *= 2;
})
2、桥接模式在事件监听中的应用
function getBeerById(id, callback) {
asyncRequest('GET', 'beer.url?id=' + id, function(resp) {
callback(resp.responseText)
});
}
elem.addEventListener('click', getBeerByIdBridge, false);
//创建一个桥，就可以获取当前的上下文对象this
function getBeerByIdBridge(e) {
console.log(this) //当前点击的node节点
getBeerById(this.id, function(beer) {
console.log('Requested Beer: ' + beer);
});
}
如果直接传入getBeerById方法，那么也可以实现，但是geiBeerById依赖上下文对象，不然无法获取对应的id，所以设计了一个getBeerByIdBridge桥来间接调用，同时在桥里面调用对应的方法，将点击事件与实现部分解耦，而且getBeerByIdBridge也可以单独调用
3、桥接模式用于组件开发
桥接模式的一个适用场景是组件开发。 我们平时开发组件为了适应不同场合， 组件相应的会有许多不同维度的变化。 桥接模式就可以应用于此， 将其抽象与实现分离， 使组件的扩展性更高。
假设我们要开发一个弹窗插件， 弹窗有不同的类型： 普通消息提醒， 错误提醒， 每一种提醒的展示方式还都不一样。 这是一个典型的多维度变化的场景。 首先我们定义两个类： 普通消息弹窗和错误消息弹窗。
function MessageDialog(animation) {
this.animation = animation;
}
MessageDialog.prototype.show = function() {
this.animation.show();
}
function ErrorDialog(animation) {
this.animation = animation;
}
ErrorDialog.prototype.show = function() {
this.animation.show();
}
// 这两个类就是前面提到的抽象部分，也就是扩充抽象类，它们都包含一个成员animation。
// 两种弹窗通过show方法进行显示，但是显示的动画效果不同。我们定义两种显示的效果类如下：
function LinearAnimation() {}
LinearAnimation.prototype.show = function() {
console.log("it is liner");
}
function EaseAnimation() {}
EaseAnimation.prototype.show = function() {
console.log("it is ease");
}
// 这两个类就是具体实现类，它们实现具体的显示效果。那我们如何调用呢？
var message = new MessageDialog(new LinerAnimation());
message.show();
var error = new ErrorDialog(new EaseAnimation());
error.show();
// 如果我们要增加一种动画效果，可以再定义一种效果类，传入即可。
总结
学习桥接模式关键是要理解抽象部分与实现部分的分离，使得二者可以独立的变化，而不必拘泥于形式。JS插件灵活的变化，适用场景的多变就非常适合使用这种模式来实现。使用桥接模式最重要的是要找出系统中不同的变化维度。
桥接模式缺点：
每使用一个桥接元素都要增加一次函数调用，这对应用程序的性能会有一些负面影响。提高了系统的复杂程度。如果一个桥接函数被用于连接两个函数，而其中某个函数根本不会在桥接函数之外被调用，那么此时这个桥接函数就不是非要不可的。
桥接模式的优点：
分离了抽象和实现部分，将实现层（DOM 元素事件触发并执行具体修改逻辑）和抽象层（ 元素外观、尺寸部分的修改函数）解耦，有利于分层；
提高了可扩展性，多个维度的部件*组合，避免了类继承带来的强耦合关系，也减少了部件类的数量；
使用者不用关心细节的实现，可以方便快捷地进行使用；
桥接模式的缺点：
桥接模式要求两个部件没有耦合关系，否则无法独立地变化，因此要求正确的对系统变化的维度进行识别，使用范围存在局限性；
桥接模式的引入增加了系统复杂度；
桥接模式的适用场景
如果产品的部件有独立的变化维度，可以考虑桥接模式；
不希望使用继承，或因为多层次继承导致系统类的个数急剧增加的系统；
产品部件的粒度越细，部件复用的必要性越大，可以考虑桥接模式；
桥接模式与其他设计模式的区别
桥接模式和策略模式
桥接模式： 复用部件类，不同部件的实例相互之间无法替换，但是相同部件的实例一般可以替换；
策略模式： 复用策略类，不同策略之间地位平等，可以相互替换；
桥接模式与模板方法模式
桥接模式： 将组成产品的部件实例的创建，延迟到实例的具体创建过程中；
模版方法模式： 将创建产品的某一步骤，延迟到子类中实现；
桥接模式与抽象工厂模式
这两个模式可以组合使用，比如部件类实例的创建可以结合抽象工厂模式，因为部件类实例也属于一个产品类簇，明显属于抽象工厂模式的适用范围，如果创建的部件类不多，或者比较简单，也可以使用简单工厂模式