给出一个比较老的链接http://www.uza.lt/codex/as3-global-object/
当时这个出来还是蛮受欢迎的
就我当年而言，我是不喜欢这种监听的，其实现在也不大满意
原因有蛮多，就当年而言，我的代码模式是我更乐意在一个逻辑体中对数据集合修改后或者发事件，或者直接调用绘制工具保持某个显示保持数据更新
因为一直做游戏的原因，其实发事件并不是一种高效的办法，这里要特指下是那种直接new一个event dispatch出去，因为无形中会产生创建的消耗，而as3创建一个对象并不快，虽然很多人很乐意谈论gc机制如何如何，但要意识到一点就是：gc是消耗cpu达到清理的目的。能事先预估到这种更新频率高的发送调用，还不如直接用内存换速度的方法实现
这又会引入一个新的争执，就是事件机制好不好，看了上面这段，估计都认为我厌恶事件，其实一个玩意采不采用事件发送，这要看具体想实现什么要的逻辑功能
比如一个component，大家会发现为什么open source包给出的component都是dispatch event来实现的，原因也很简单，因为人家给出的是共享给大家，方便通用性而言，事件机制相当不错，如果一个项目的某个component只有一个地方使用到，那我觉得还发送事件就有点问题了
对于最上面的地址，重温下代码，发现不是跟flex sdk中的ChangeWatch功能很类似么，也就是mxml中用得很频繁，也是相当核心[BIndable]和在flex component的属性中是使用{}，把mxml解析出as3再编译，其实就是使用ChangeWatch实现，你的绑定数据集合跟上面的GlobalObject就差不多了
对于现在我在做的这个项目，其实框架我还保持了flex框架，因为这为我节省了很多ui的功夫，包括皮肤制作、组件功能相当多的部分，至于很多人喜欢谈论的flex框架大小问题，如果我重复去造下轮子，估计大小比flex的还大，而且用不到的功能组件，你是可以方便剔除掉的，比如一个button，自己写一个当然小了，但焦点管理、tab管理、皮肤九宫其实都未做考虑，而这我都需要
同样，这也是我保持使用[Bindable]的根本缘由，我见过很多自己用as3重做一个ui框架失败的项目，而且我也没有时间耗在这上面，再说小心点使用，其实内存效率都可以保持在一个我非常满意的效率，只是有一点比较不爽的就是，我虽然有办法让vo（就是上面的GlobalObject）在我需要的时候停止发送事件，也有办法在需要的时候重新激活继续发事件，但这步骤相当的麻烦--就是让给我不爽呀
我估计Cairngorm普及了这么久，估计很多人已经很习惯的把ModelLocator进行绑定，之后分发到各个不同的flex component，这是Cairngorm最核心的，也因为这个，它一出现跟flex框架相当的吻合，不过其他地方的转发，比如command delegate在具体项目中，是相当浪费的行为，就是说Cairngorm太学术性质了
不过就是因为太习惯ModelLocator的绑定，也导致了非常多的滥用绑定，而事后发现"哎呀，一用flex框架、Cairngorm内存就这么大呀，而且越跑内存越大"，对于一般自己写的，event是比如容易去移除的，毕竟你写的嘛，但bindable是生成的，当然也是有办法去移除，就是不那么方便了
所以要回到原来，就是ModelLocator的绑定不应该这么随意，这其实太多教程、代码例子起了很不好的示范，就是把远程数据拿过来就直接绑定，利用PropertyChangeEvent分发到flex component界面，这看起来很爽，只要注意远程Delegate数据赋值，一切界面是视图上调整下，一个实例出来了，简单，清爽，代码也不多
其实这些实例大多对于本身来说他做法也没错，错的只是太过简单了，因为一个界面数据集合永远都不会是界面显示数据集合这么简单，内在相互逻辑都被忽略掉了，明白我的意思没，ModelLocator中有太多其实不需要绑定的数据被迫绑定，而且不会去解除绑定
Good Luck & Have Fun!
