Android, BREW中Observer（观察者）模式的两种表现

Observer模式无疑是最伟大的设计模式之一。 她被用来解耦一对多的关系，并对“多”的变化进行隔离。 现代移动平台中，更是随处可见她的身影。 本文将从Android，BREW两个移动平台中，一窥其迷人身姿。

 

Listener机制。 在BREW和Android中，同时都提供了Listener机制。这是血统纯正的Observer模式体现。 BREW中的IModel的AddListener和Android中的View的AddXXXListener就是两个很好的例子。 在这种纯种Observer模式下，我们需要明确的创建或者得到Object（主题，被观察者）， 在Android中创建或者Find的View就是Object，BREW中通过QueryInterface得到的IModel也就是Object。 有了Object后，我们还需要明确的构建Observer， 这在BREW中，其实就是一个包含回调函数的结构体，在Android中，就是创建的一个Listener对象实例。 这两种差异，其实是由两种语言（C和java）决定的。再之后，我们需要明确的加入或者退出观察者队列，在BREW中，这是通过IModel_AddListener，Android中通过View的AddXXXListener实现。 Listener机制无需框架的参与，直接由Object与Observer实现全部，并与Object以及Observer实例的生命周期绑定，仅在Object和Observer实例均存在时才有效。 具体的通知实现，BREW基于命令回调，而Android则基于对象委派，这同样是由于两种不同的语言部分决定的。

 

 

Notifier和BroadcastReceiver。 这两种其实是变种的Observer模式表现。 他们都可以通过配置文件（BREW中为MIF文件，Android中为AndroidManifest.xml）或者代码（BREW中为ISHELL_RegisterNotify， Android中为registerReceiver）来注册通知。 这种注册方式仅仅是声明感兴趣的内容，却不需要创建Object，Observer实例并加入观察。由于脱离了对实际Object，Observer实例的依赖，使得这种通知场景是全局生命期的，从而即使观察者根本不在运行，也能进行观察和通知。这种特点使得其更加适合系统级事件的通知解决方案。再来看其实现，则需框架的参与。此时Object和Observer间不直接耦合通信，观察注册信息转由框架维护。Observer向框架注册，Object向框架发出通知而无需关心究竟谁注册了通知，而框架在运行时再查询自己的通知注册信息，从而知道哪些组件对当前的通知感兴趣，并投递给他们，如果实例不存在，则先创建他们。

 

 

从上述的分析中可以看到，Listener机制单由Object，Observer独立实现，依赖于相互的存在，故而只适合运行时的局部生命期的场景。 而Notifier或者BroadcastReceiver依赖于框架，不直接依赖于Object，Observer，故而适合全局生命期的场景。 所以，我们在设计组件时，如果期望提供通知机制，应该根据其实际需求，选择相应的机制。