FishiGUI：观察者模式

观察者模式的设计意图：

• 定义对象之间多对一的依赖关系，也即多个对象依赖于一个对象的关系，同时保证，当被依赖的对象状态发生变化时，所有的依赖者会被自动地通知。观察者模式的另一个名称是“”出版-----订阅模式“：当被依赖的对象向外发布自己的状态，而此前订阅了该状态的所有对象都会得到通知
• 当一个对象需要通知另外一些对象，而无法预知哪些对象将被通知时，通过观察者模式就可以减弱通过对象和被通知对象之间的耦合关系
• 当一个模块（模块A）的变化需要另外一个模块（模块B）相应的修改，而你不知道有多少个类会被修改，使用观察者模式就可以切断这种依赖关系，即模块A的变化不在影响模块B，模块B也无需做任何修改，这时模块B对模块A的依赖关系由直接依赖转变为间接依赖，具体的依赖关系是由模块A动态设定的

观察者模式的基本结构：

主题类（Subject）：即被观察者类的基类，它管理所有的观察者，并提供添加和删除观察者的方法

观察者类（Observe）：定义一个通知接口来接受主题类发来的通知消息

具体的主题类（ConcreteSubject）：即具体的被观察这类，它针对不同的需求，实现具体的主题属性和方法，决定何时发送通知消息等等

具体的观察者类（ConcreteObserver):针对不同的需求，实现具体的通知接口，以接受具体的主题类发来的通知消息，并且根据需要对消息进行特定的处理

观察者模式的实现：

FishiGUI系统中的观察者模式：

使用观察者模式的原因：根据架构分析结果，在框架层和操作系统适配器层，有几个类和消息传递相关，即操作系统适配器会在适当的时候，发送消息给应用程序，屏幕和定时器管理器者三个类。当操作系统适配器类接收到系统消息后需要根据系统消息的类型，把消息发送给不同的对象，虽然不存在一对多的依赖关系，但是使用观察者模式可以减少耦合同时解决无法确定每一个消息由框架层的哪个类来接受的问题

对于每一类系统消息，需要记录一个接受该消息的观察者，而且FishiGUI系统规定，每一类消息只能有一个观察者（当然，同一个观察者可以观察多类消息）---我认为和观察者模式定义的不一样是因为消息时按照职责链表传递的，在FG_OSAdaptor类中定义一个数组，该数组用来保存每个消息类型对应的观察者对象指针，观察者注册时，需要提供他想注册的消息类型，然后观察者的指针就会被记录在数组的相应位置，注册的前提是该观察类实现了观察者类接口

当FG_OSdrawInterface类接收到系统消息时，只要从数组中查询出该系统消息对应的观察者指针，然后调用该指针的OSMessage方法，就可以把消息发送给观察者了