我理解的观察者模式

首先对于观察者模式的定义 ：当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。

如下图这样：

在观察者模式里面，它只需维护一套观察者（Observer）的集合Subject，这些Observer实现相同的接口，Subject只需要知道，通知Observer时，需要调用哪个统一方法就好了, 而不是需要每次变更都更改Observer的内部属性与方法，避免了产生紧耦合的坏处。

在我的项目里面也应用到了观察者模式，

比如断线重连的逻辑：

预先写好游戏模块的更新方法与更新逻辑(如上图的Observer)，

在业务逻辑里面把要记录观察的数据通过

存放到 sessionStorage里面(Subject)，然后每次当用户断线时候 从sessionStorage取数据内容，

通过数据驱动视图，来更新(Observers)实现游戏的一个断线重连方案。

优点：

1.首先整体逻辑的耦合度大大降低，数据结构更加严谨合理。

2.对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节。

3.数据驱动视图之间的逻辑与更新分离开，使得程序的可扩展性更强。

缺点:

1.如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。

2.多个观察者内部循环引用监听时，容易导致程序出错。

体会：

从表面上看：观察者模式里，只有两个角色 —— 观察者 + 被观察者。

从内部层次看：观察者和被观察者，其实是松耦合的关系，依旧存在着依赖的关系。

应用上：观察者模式，多用于单个应用内部(游戏大厅内的—子游戏状态监听)

最后要说的话：一个系统架构的设计，往往要根据具体情况，使用适合项目的设计模式才会达到理想状态。