1616前端App框架设计思路的变迁——观察者模式由拉转向推

观察者模式又分为“推”和“拉”两种模式。

 

从日常生活举例说明：订报纸。报商给我们送上门来，这是推模式；我们自己上报亭取，这是拉模式。

从代码上二者的区别举例说明： 拉模式是当通知来之时，通知的函数不带任何相关的信息，而是要订阅者主动去“拉”信息； 推模式是当通知来之时，把所有相关信息都通过参数的形式“推给”订阅者。可以参见下图加以理解。假定：App是消息订阅者，SubjectBase和Subject是消息制造者，Observer是中间观察者。

老框架App之间进行交互很困难，需要在框架端扩展很多自定义事件，然后其他App去实现事件响应函数。如果采用老框架，自定一个事件很费劲，首先需要修改上图旧框架里的notify()实现，然后App要实现自定义事件的响应函数，还要做事件容错处理（有些App没有实现事件响应函数），也即框架和具体App两处都要开刀。 

经过一番需求演化之后，App也具备了Subject的“发布通知”的能力，也即“任何APP可以发出通知，可以侦听自己感兴趣的消息”，最终演化成下图。

是不是简单多了？这种思想最终也有利于自定义App事件的方便，方便App之间进行交互，比如App1想定义一个事件，App2想侦听App1的这个事件，只需要App2.listen("自定义事件1")，然后App1.notify("自定义事件1","附加数据")即可。这样所有的修改都放到了具体App这边，1616作为一个即将开放的App平台，把自主权下放给App开发人员应该是明智的方向。当然“自定义事件1”这个事件名是两个App约定好的。否则事件名不对，不会响应，这是需要注意的。

一般来说，推模式可以更多地减少耦合，维护上方便改动较小，但缺点是不管信息有用没有都推给了App。然而，前端通过javascript通信，推模式传递冗余的信息所占用的开销几乎可以忽略不计了，因为javascript程序运行在用户本机，传输速度是相当快的。