代码重构，用Observer模式进行封装时遇到问题疑问。
小弟现在遇到一个问题,FrameWork(框架)在与各个不同的Controller(不同用户交互tab页)进行通信，我用Observer模式进行封装，两者是一对多的关系，每一个Controller是在FrameWork中开始运行时作为dll加载上来，并把Controller的hwnd保存到一个链表里面，这个list(FrameWork中的成员)保存了所有Controller的hwnd，Framework与Controller之间的通信只能通过发消息(因为是不同的dll),现在的问题是：Framework对目标数据的修改如Add，Delete，Modify等等的操作都需要通知每一个Controller，所以每个Controller都需要在OnCommand中对 对应的消息进行相应。这样子的后果是Framework要添加一个消息，每一个Controller就要去做对应的处理分支(添加个case),这样的耦合度太大了，但是我却不知道用什么好的方法可以解耦，望各位指点。

[解决办法]
给 Controller 添加一个父类A，专门用来接受 来自FrameWork的消息， 剩下的处理下方给 各个 Controller。 其中父类A中加一个 虚函数 dosomeThing，给它一个默认的处理流程, 在该父类A的OnCommand 中相应 消息,并调用这个虚函数dosomeThing。。 由各个子类Controller 重载虚函数，做出处理。。

这样子就变成了 FrameWork 与 父类A的通信过程， 每个子类也不用添加 OnCommand了。。


另外， 你这个不叫做， 观察者， 叫做迭代器比较合适。。

观察者是 Controller 通知 FrameWork 自己的数据变了， FrameWork 进行相应。。
[解决办法]
1. 你的意思是 FrameWork 给 Controller 发消息时 Controller 们 中 有选择的相应 吗？ 如果是有选择的相应， 你可以按照我说的 给 基类A 做一个ID， FrameWork 发送消息的时候顺便把 需要接受消息的Controller ID 加上。 然后基类A接到 这个消息后， 判断消息中的ID是否与 自己的ID相符合， 如果相符合则调用 doSomeThing。 这样也可以避免每个Controller 都要实现 OnCommand了

2. 我不赞同你把 选项板 放在dll中， 而且还设计了这么多的dll。 我觉得UI就是UI, 与主程序都放在一起比较合适， 底层可以封装不同的处理逻辑类， 放在不同的dll中。。
把 UI的处理放在dll中 有点 过度追求 模块化设计了。。
[解决办法]
如果每个Controller都要处理 FrameWork的消息的话， 不妨试一下2楼的那个思路， 应该可行。
[解决办法]
你可以使用模板方法