JavaScript Design Patterns: Mediator
The Mediator Design Pattern
The Mediator is a behavioral design pattern in which objects, instead of communicating directly with each other, communicate only through a central message passing object (the Mediator). The Mediator pattern facilitates both loose couple and high cohesion.
Loose Coupling
Coupling measures the degree to which program modules rely on other modules. Loose couplingimplies each component can operate or be tested independently of other components. Tight coupling implies each component "knows" the details or inner workings of other components. The Mediator almost entirely eliminates coupling between participating objects by becoming the only outside point of contact. All a module needs to know is how to broadcast messages through the Mediator — it doesn't matter whether 0, 1, or even 100 other modules act on those messages.
- What's good about loose coupling? Loose coupling facilitates rapid prototyping by getting rid of code dependencies. Components can broadcast and/or listen for messages without worrying about the rest of the system. Messages can be completely ignored, or handled by any number of other components at once. You can add and remove listening objects without changing anything about how those messages are broadcast. It is typically much easier to add new features to software when its components are loosely coupled.
- What's bad about loose coupling? By inserting the Mediator between objects, components always communicate indirectly, which may cause a very slight performance hit. Also, due to the very definition of loose coupling, there's no way to tell how the system might react to a message by only looking at the point of broadcast. For some, this may take a shift in thinking. This is actually good, though — If components call each other directly, for example using
myObject.someFunction(args)
, then one change in how your program works may cause a ripple effect of changes through several modules. TL;DR: tight coupling causes headaches
High Cohesion
Cohesion is a measure of how focused a piece of code is. High cohesion implies a component's properties and methods are strongly related, and work toward one or more closely related tasks.Low cohesion implies a component may handle two or more unrelated or dissimilar tasks.
- What's good about high cohesion? Lower maintenance cost, whether that means money, time, stress, or some combination thereof. Software modifications tend not to affect other parts of the program, which means you can make them in less time and with more confidence. Reading and understanding your code also becomes easier when related tasks are grouped. High cohesion also facilitates code reuse, which again saves time and money. If you need to perform the same task in another application, you know where to go for the solution, and you know unrelated or unnecessary code won't "tag along".
- What's bad about high cohesion? I could come up with no obvious downsides to high cohesion — if you know any, please leave a comment for the sake of completeness!
The following example was built on ideas presented by Paul Marcotte. I especially like his comparison between the Mediator pattern and the Observer pattern:
"Instead of using the Observer pattern to explicitly set many-to-many listeners and events, Mediator allows you to broadcast events globally across colleagues."— Paul Marcotte
Mediator = function() {
var debug = function() {
// console.log or air.trace as desired
};
var components = {};
var broadcast = function(event, args, source) {
if (!event) {
return;
}
args = args || [];
//debug(["Mediator received", event, args].join(' '));
for (var c in components) {
if (typeof components[c]["on" + event] == "function") {
try {
//debug("Mediator calling " + event + " on " + c);
source = source || components[c];
components[c]["on" + event].apply(source, args);
} catch (err) {
debug(["Mediator error.", event, args, source, err].join(' '));
}
}
}
};
var addComponent = function(name, component, replaceDuplicate) {
if (name in components) {
if (replaceDuplicate) {
removeComponent(name);
} else {
throw new Error('Mediator name conflict: ' + name);
}
}
components[name] = component;
};
var removeComponent = function(name) {
if (name in components) {
delete components[name];
}
};
var getComponent = function(name) {
return components[name]; // undefined if component has not been added
};
var contains = function(name) {
return (name in components);
};
return {
name : "Mediator",
broadcast : broadcast,
add : addComponent,
rem : removeComponent,
get : getComponent,
has : contains
};
}();
And here's how to use it:
Mediator.add('TestObject', function() {
var someNumber = 0; // sample variable
var someString = 'another sample variable';
return {
onInitialize: function() {
// this.name is automatically assigned by the Mediator
alert(this.name + " initialized.");
},
onFakeEvent: function() {
someNumber++;
alert("Handled " + someNumber + " times!");
},
onSetString: function(str) {
someString = str;
alert('Assigned ' + someString);
}
}
}());
Mediator.broadcast("Initialize"); // alerts "TestObject initialized"
Mediator.broadcast('FakeEvent'); // alerts "Handled 1 times!" (I know, bad grammar)
Mediator.broadcast('SetString', ['test string']); // alerts "Assigned test string"
Mediator.broadcast('FakeEvent'); // alerts "Handled 2 times!"
Mediator.broadcast('SessionStart'); // this call is safely ignored
Mediator.broadcast('Translate', ['this is also safely ignored']); http://arguments.callee.info/2009/05/18/javascript-design-patterns--mediator/
JavaScript Design Patterns: Mediator的更多相关文章
- Learning JavaScript Design Patterns The Module Pattern
The Module Pattern Modules Modules are an integral piece of any robust application's architecture an ...
- AMD - Learning JavaScript Design Patterns [Book] - O'Reilly
AMD - Learning JavaScript Design Patterns [Book] - O'Reilly The overall goal for the Asynchronous Mo ...
- Learning JavaScript Design Patterns The Observer Pattern
The Observer Pattern The Observer is a design pattern where an object (known as a subject) maintains ...
- Learning JavaScript Design Patterns The Singleton Pattern
The Singleton Pattern The Singleton pattern is thus known because it restricts instantiation of a cl ...
- Javascript Design Patterns - Js Class
JavaScript is a class-less language, however classes can be simulated using functions. eg: // A car ...
- Learning JavaScript Design Patterns The Constructor Pattern
In classical object-oriented programming languages, a constructor is a special method used to initia ...
- javascript design patterns
http://jsdesignpatterns.com/ http://www.joezimjs.com/tag/design-patterns/ http://codecube.net/#archi ...
- [Design Pattern] Mediator Pattern 简单案例
Meditor Pattern,即调解模式,用一个调解类类处理所有的沟通事件,使得降低多对象之间的沟通难度,属于行为类的设计模式.为了方便理解记忆,我也称其为,沟通模式. 下面是一个调解模式的简单案例 ...
- Design Patterns All in One (JavaScript Version)
Design Patterns All in One (JavaScript Version) JavaScript 设计模式 JavaScript 数据结构 23种设计模式分为 3 大类: 创建型模 ...
随机推荐
- Jquery图片随滚动条加载
很久以前的写的Jquery图片随滚动条加载,现在不是什么新技术,应用也很广泛,大大提高图片多的页面打开速度! 有需要的朋友看看吧!有什么意见或建议欢迎留言交流! Demo.html 源码: < ...
- Eclipse下建立geoserver源码工程
摘要:本文详细阐述,如何基于geoserver源码构建eclipse工程文件,操作过程中除用到jdk.eclipse以外,还有git和maven,操作系统为windows8. 1安装Git 从(htt ...
- Windows Azure 虚拟网络配置(Site to Site)
上篇我们创建了Point to Site的虚拟网络连接,来满足客户端到云端网络的连接.本篇文章我们将创建Site to Site的虚拟网络连接,以满足本地网络到云端的网络连接. 创建与配置过程与上篇较 ...
- Linux下动态库生成和使用
Linux下动态库生成和使用 一.动态库的基本概念 1.动态链接库是程序运行时加载的库,当动态链接库正确安装后,所有的程序都可以使用动态库来运行程序.动态链接库是目标文件的集合,目标文件在动态链接库中 ...
- Python内置方法的时间复杂度(转)
原文:http://www.orangecube.net/python-time-complexity 本文翻译自Python Wiki本文基于GPL v2协议,转载请保留此协议. 本页面涵盖了Pyt ...
- TransactionScope事务对多个数据库的操作
.Net 2.0引入了轻量级事务管理器(Lighweight Transaction Manager),即System.Transactions.TransactionManager. 轻量级事务管理 ...
- 安装glibc2.7
参考链接http://fhqdddddd.blog.163.com/blog/static/18699154201401722649441/ /lib/libc.so.6: version `glib ...
- iis 支持html执行php输出
iis 支持html执行php输出 2012-07-25 10:50:23| 分类: PHP|举报|字号 订阅 在HTML中有个简单的的PHP随机数需要输出,例如: <td backg ...
- windows下php cli模式,提示出错
搞一下php cli,一直提示,找不到php_pdo_mssql.dll模块 原来是在php.ini加载了该模块,但ext下又没有该模块 即便下载了一个php_pdo_mssql.dll,但还是会提示 ...
- 接口是干爹, 继承是亲爹 ---JAVA
接口(interface)是干爹, 因为你可以有很多很多的干爹爹... 继承(extends)是亲爹, 因为你只能有一个父类, 只有一个亲生的父亲. 单继承,多接口?./>./..