哇－是個危險的題目，對嗎？我們對於什麼是本質的理解當然會隨著我們對要解決問題的理解而改變。因此我不會說謊——一年前我所理解的本質很不幸並不完整，因為我確信我將要寫的東西已經快伴隨我有6個月之久。所以，這篇文章是我在發現JavaScript中成功的運用客戶端訊息模式的一些關鍵要點時的一個掠影。
1.) 瞭解中介者與觀察者的差異
大多數人在描述任何事件/訊息機制的時候喜歡套用「發布者/訂閱者」(pub/sub)——但我認為這個術語不能很好的與抽象建立聯繫。當然，從根本上說，一些東西訂閱了另一些東西發布的事件。但是發布者與訂閱者在何等層次上封裝在一起有可能使一個好的模式變得暗淡無光。那麼，差別在什麼地方呢？
觀察者
觀察者模式包括了被一個或多個觀察者所觀察到的某個對象。典型的，該物件記錄下所有觀察者的痕跡，通常是用一個list來儲存觀察者註冊的回呼方法，這些是觀察者為了接收通知而訂閱的。 注意: (哦，雙關語，我有多愛他們啊)（譯者註：Observe 觀察、注意）
var observer = {
listen : function() {
console.log("Yay for more cliché examples...");
}
};
var elem = document.getElementById("cliche");
elem.addEventListener("click", observer.listen);
一些需要注意的是:
* n事實上不是無限的，但為了討論的目的，它指我們永遠也達不到的極限
中介者
中介者模式在一個物件與一個觀察者之間引入了一個「第三方」－有效的將二者解耦而且將他們之間如何通信封裝起來。一個中介者的API可能像「發布」、「訂閱」、「取消訂閱」一樣簡單，或者某個領域範圍內的實作可能被提供用來隱藏這些方法於某些更有意義的語意之中。大多數我用過的伺服器端的實作更傾向於領域範圍而不是更簡單，但是並沒有對一個通用的中介者有任何規則限制！並不罕見，有種想法認為一個通用的中介者是一種資訊經紀人。無論何種情形，結果都一樣－特定對象與觀察者之間不再互相直接知曉：
// It's fun to be naive!
var mediator = {
_subs: {},
// a real subscribe would at least check to make sure the
// same callback instance wasn't registered 2x.
// Sheesh, where did they find this guy?!
subscribe: function(topic, callback) {
this._subs[topic] = this._subs[topic] || [];
this._subs[topic].push(callback);
},
// lolwut? No ability to pass function context? :-)
publish : function(topic, data) {
var subs = this._subs[topic] || [];
subs.forEach(function(cb) {
cb(data);
});
}
}
var FatherTime = function(med) { this.mediator = med; };
FatherTime.prototype.wakeyWakey = function() {
this.mediator.publish("alarm.clock", {
time: "06:00 AM",
canSnooze: "heck-no-get-up-lazy-bum"
});
}
var Developer = function(mediator) {
this.mediator = mediator;
this.mediator.subscribe("alarm.clock", this.pleaseGodNo);
};
Developer.prototype.pleaseGodNo = function(data) {
alert("ZOMG, it's " + data.time + ". Please just make it stop.");
}
var fatherTime = new FatherTime(mediator);
var developer = new Developer(mediator);
fatherTime.wakeyWakey();
你可能会想，除了特别纯粹的中介者实现，特定对象不再负有保存订阅者列表的责任，而且“时光老人”(FatherTime)与“开发者”(Developer)实例永远没法真正互相知道。他们只是共享了一个信息——将如我们今后所见，这是一个很重要的合约。 “很好，Jim。这对我而言仍然是发布者/订阅者，那么重点呢？我选择某个方向真的会有区别吗？”哦，继续吧，亲爱的读者们，继续吧。
2.) 了解什么时候使用中介者和观察者
使用本地的观察者和中介者，即写在组件当中的，而中介者看起来又像远程的组件间通信。不管怎样。我对待这种情况的原则虽然是——tl;dr（too long; don't read)（太长，不读了）。但无论如何，反正串联在一起最好。
要我简捷地说真是麻烦，就像把几个月来的细致体验压缩到装不下140个字的沟里。现实中回答这个问题肯定不简洁。所以有一个长版本的解释：
观察者除了关心数据映射之外还有必要引用别的项目吗？例如Backbone.View视图有各种理由直接引用它的模型。这是非常自然的关系，视图不仅要在模型改变时进行渲染，还需要调用模型的事件处理。如果段首的问题答案是”yes“，那观察者就是有意义的。
如果观察者和观察对象的关系仅仅是依赖数据，那我愿意使用中介pub/sub方式。两个Backbone.View视图或模型之间的通信，用观察者是合适的。比如控制导航菜单的视图发出的信息，是面包屑（breadcrumb）挂件需要的（响应当前的层级）。挂件不需要引用导航视图，它只需要导航视图提供信息。更关键的，导航视图也许不是唯一的信息来源，别的视图可能也可以提供。此时，中介pub/sub模式是最理想的——而且自身扩展性良好。
看起来这样又好又全面，但是其实还有一个露点：如果我给对象定义一个本地事件，既想要观察者直接调用，又可以被订阅者间接访问到，怎么办？这就是我为什么说要串联在一起：你推送或者桥接本地事件到消息组去吧。需要些更多代码？很有可能——但是总比你把观察对象传递给所有观察者，一直紧耦合下去的情况好。然后，我们可以很好地继续以下两点...
3.) 选择性的“提交”本地事件到总线
最开始我几乎只用观察者模式来在JavaScript中触发事件。这是我们一次又一次遇到的模式，但更流行的客户端辅助库行为方式根本上来说是混合中介者的，给我们提供了就像它们是观察者模式的API。我最初写postal.js的时候，开始走进“为所有事物搭中介”的阶段。在我写的原型与构造函数中，分布各处的发布与订阅的调用并不罕见。当我从这个改变中自然的解耦受益时，非基础的代码开始似乎充满了相关于基础的部分。构造函数到处都要带上一个通道，订阅被当作新实例的一部分被创建，原型方法直接发布一个数值到总线（甚至本地的订阅者都不能直接的而必须监听总线以获得信息）。将这些明显关于总线的东西纳入app的这些部分，开始像是代码的味道。代码的“叙述”似乎总是被打断，如“噢，将这个向所有订阅者发布出去”，“等等！等等！监听这个通道那个事情。好，现在继续吧”。我的测试忽然开始需要依赖总线来做低层次的单元测试。而这感觉有点不对劲。
钟摆摆动的指向了中间，我认识到我应该保持一个“本地API”，并且在需要的时候通过一个中介者为应用扩展其可以触及的数据。 例如，我的backbone视图与模型，仍然用普通的Backbome.Events行为来给本地观察者发送事件(就是说，模型的事件被它相应的视图所观察)。当app的其它部分需要知道模型的变化时，我开始通过这些行将本地事件与总线桥接起来：
var SomeModel = Backbone.Model.extend({
initialize: function() {
this.on("change:superImportantField", function(model, value) {
postal.publish({
channel : "someChannel",
topic : "omg.super.important.field.changed",
data : {
muyImportante: value,
otherFoo: "otherBar"
}
});
});
}
});
重要的是要认识到，当有可能透明的推送事件到消息总线时，本地事件和消息必须被认为是分开的合约——至少概念上如此。换句话说，你要能够修改“内部的/本地的”事件而不破坏消息合约。这是要在脑海中记住的重要事实——否则你就是为紧耦合提供了一个新的途径，在一个方法上走反了！
所以理所当然，上述的模型是可以在没有消息总线的情况下被测试。而且如果我移去桥接在本地事件与总线之间的逻辑，我的视图与模型依然工作得毫无不畅。但是，这可是七行的例子（尽管格式化了）。 仅仅桥接四个事件就需要几乎三十行的代码。
噢，你怎样才能二者兼顾呢—— 在适合直接观察者时本地通知，同时使涉及事件可以扩展，以便你的对象不必给所有对象都发送一圈——不需要代码膨胀。通知怎样才能很少的代码又有更多的味道呢？
4.)在你的构架中隐藏样板
这并不是说上面的例子中的代码 —— 将事件接入总线 —— 的语法或概念是错误的（假设你接受本地和远程/桥接事件的概念）。然而，这是一个很好的体现在代码基础之上培养良好习惯的作用的例子。有时我们会听到类似“代码实在太多了”的抱怨（特别是当 LOC 作为代码质量的唯一判定者时）。 当这种情况下，我表示赞同。 它是一个可怕的样板。 下面是我在桥接 Backbone 对象的本地事件到 postal.js 时使用的模式：
// the logic to wire up publications and subscriptions
// exists in our custom MsgBackboneView constructor
var SomeView = MsgBackboneView.extend({
className : "i-am-classy",
// bridging local events triggered by this view
publications: {
// This is the more common 'shorthand' syntax
// The key name is the name of the event. The
// value is "channel topic" in postal. So this
// means the bridgeTooFar event will get
// published to postal on the "comm" channel
// using a topic of "thats.far.enough". By default
// the 1st argument passed to the event callback
// will become the message payload.
bridgeTooFar : "comm thats.far.enough",
// However, the longhand approach works like this:
// The key is still the event name that will be bridged.
// The value is an object that provides a channel name,
// a topic (which can be a string or a function returning
// a string), and an optional data function that returns
// the object that should be the message payload.
bridgeBurned: {
channel : "comm",
topic : "match.lit",
data : function() {
return { id: this.get("id"), foo: 'bar' };
}
},
// This is how we subscribe to the bus and invoke
// local methods to handle incoming messages
subscriptions: {
// The key is the name of the method to invoke.
// The value is the "channel topic" to subscribe to.
// So this will subscribe to the "hotChannel" channel
// with a topic binding of "start.burning.*", and any
// message arriving gets routed to the "burnItWithFire"
// method on the view.
burnItWithFire : "hotChannel start.burning.*"
},
burnItWithFire: function(data, envelope) {
// do stuff with message data and/or envelope
}
// other wire-up, etc.
});
显然你可以用几种不同的方式做这些——选择总线式的框架——这要比样板方式少很多无关内容，而且为Backbone开发人员所熟知。当你同时控制事件发送器和消息总线的实现时，桥接要更容易。这里有个将monologue.js发送器桥接到postal.js的例子：
// using the 'monopost' add-on for monologue/postal:
// assuming we have a worker instance that has monologue
// methods on its prototype chain, etc. The keys are event
// topic bindings to match local events to, and if a match is
// found, it gets published to the channel specified in the
// value (using the same topic value)
worker.goPostal({
"match.stuff.like.#" : "ThisChannelYo",
"secret.sauce.*" : "SeeecretChannel",
"another.*.topic" : "YayMoarChannelsChannel"
});
以不同的方式使用样板是令人愉快的好习惯。现在我可以分别独立的测试我的本地对象，桥接代码，甚至测试二者合一的生产&消费期待的消息过程等等。
同样重要的是要注意到，如果我需要在上述的场景访问普通的postal API，没有什么可以阻止我这么做。没有丢失灵活性这么就等于成功了
5.) 消息是合约——要明智的选择实现方式
有两种将数据传递给订阅者的方法——也许可以给他们贴上更“官方”的标签，我将如此描述他们：
看看这些例子：
// 0-n args
this.trigger("someGuyBlogged", "Jim", "Cowart", "JavaScript");
// envelope style
this.emit("someGuyBlogged", {
firstName: "Jim",
lastName: "Cowart",
category: "JavaScript"
});
/*
In an emitter like monologue.js, the emit call above
would actually publish an envelope that looked similar
to this:
{
topic: "someGuyBlogged",
timeStamp: "2013-02-05T04:54:59.209Z",
data : {
firstName: "Jim",
lastName: "Cowart",
category: "JavaScript"
}
}
*/
经过一段时间，我发现封套方式比0-n参数方式要少很多很多麻烦（与代码）。"0-n参数"途径的挑战主要在于两个原因（就我的经验而言）：第一，很典型的是“当事件触发时，你还记得要传递哪一个参数吗？不记得？好，我想我会看看触发的源头”。不是一个真正意义上的好方法，对吗？但它可以打断代码的正常流程。你可以用一个调试工具，检测执行条件下的参数值并由此推断基于这些数值的”标签“，但哪个更简单呢——看到一个”1.21“的参数值，困惑于它的意义，或者检测一个对象并发现{千兆瓦：1.21}。第二个原因是由于伴随事件传送可选的数据，以及当方法签名变得更长带来的痛苦。
"说实话，Jim，你这是在搭车棚。"或许是的，但是一段时间以来我一直看到代码的基础在扩充与变形，简单的包含一两个参数的原始事件，在其间包含了可选的参数以后开始变得畸形：
// 最开始是这样的
this.trigger("someEvent", "a string!", 99);
// 有一天， 它变得包含了一切
this.trigger("someEvent", "string", 99, { sky: "blue" }, [1,2,3,4], true, 0);
// 可是等等——第4和第5个参数是可选的，因此也可能传的是：
this.trigger("someEvent", "string", 99, [1,2,3,4], true, 0);
// 噢，你还检查第5个参数的真/假吗?
// 哎呦！现在是早先的参数了……
this.trigger("someEvent", "string", 99, true, 0);
如果有任何資料是可選的，將沒有圍繞它的測試。但需要更少的程式碼，需要能更具擴展性，特別典型的是能自解釋（感謝這些成員名字）以便能在逐一傳送給訂閱者回調方法時，對一個對象進行那種測試。我仍然在不得不用"0-n參數"的地方使用它，但如果由我決定，將是一直用封套的方法——我的事件發送者和訊息總線都是這樣。 （表示我有偏見，monologue與postal共享同一個封套的資料結構，去掉了monologue不用的通道）
因此－得承認用來傳送資料給訂閱者的結構是」合約「的一個部分。在封套方式這個方向，你可以用額外的元資料描述事件（不需要增加額外的參數）——這保持了方法簽名（這就是合約的一個部分）對每個事件和訂閱者一致。你也能很容易的為一個資訊結構編製版本（或在必要的時候增加其他封套層級的資訊）。如果你沿著這個方向做的話，請確保用的是一致的封套結構。
6.) 訊息」拓樸「比你想的還重要
這裡沒有銀彈。但是你要對如何命名主題與通道，以及如何設計訊息載荷的結構深思熟慮。我傾向於用兩種方法之一來映射我的模型：用一個單一的資料通道，主題的前綴採用模型的名字，後面跟著其唯一的id，然後透過它的操作({modelType.id.operation})處理，或給模型的自身通道，主題就是{id.operation}。一個恆定的習慣是在模型請求資料的時候自動回應這個行為。但並不是所有總線上的操作都是請求。可能有簡單的活動發佈到app。你是否命名主題來描述事件（理想條件下）？還是你掉進了這樣的陷阱，透過命名主題來描述某個訂閱者可能的傾向行為？例如，包含「route.changed」 抑或 “show.customer.ui」主題的訊息。一個表明了事件，另一個表明了命令。做這些決定的時候要仔細思考。命令並不壞，但在你需要請求/回應或命令之前，你會為事件所能描述的數量而吃驚的。
