Posts tagged Ogre

关于低耦合的消息传递，实现的方式有很多，哪种方法更好与具体的使用环境有关，本文使用试错的方法，逐步探索达成这一目的具体方式，并理解实现方式背后的原因。
 
面向对象的系统当中，不可避免的有大量的类间消息传递的需求：一个类需要通知另一个或几个类做些什么。
 
这种类间消息传递，简单的说，就是调用其他类的方法。
如下：
void A::OnMessageXX()
{
         B::GetInstance()->DoSomething();
}
在这里，类A需要通知类B做些事情。这种调用在所有的面向对象程序中都是极其常见的。
 
但是如果类A需要调用类B，就不可避免的产生了耦合性。虽然耦合性终归是不可能完全避免的，但是在一定程度上降低耦合性是完全可能的。
（至于为什么在设计中应该尽可能降低耦合性，不在本文的探讨范围之内）
 
上面的例子，我们使用了Singleton的模式，从全局作用域中获取了B的实例，并调用了B的相关方法。使用Singleton的一个缺点是，假若我们希望对类A编写测试代码，我们需要做一些额外的解耦合工作。（关于编写测试与解耦合，可以参考Robert C. Martin Series的Working Effectively with Legacy Code一书，该书的中译版在这）
我们也可以通过将B参数化的方法降低A与B间的耦合程度，像下面这样：
void A::OnMessageXX(B* pBInstance)
{
         pBInstance->DoSomething();
}
现在的写法要比之前的做法耦合性低，通过使用多态的方法，现在传入函数的类B指针可能是另一个实现了B的相应接口的派生类，A并不关心B接口背后的具体实现。
 
但是等等，你说，现在对类B的耦合性虽然在A中被降低了，但是依旧存在于调用A::OnMessageXX的地方。在那里我们还是需要取得B的实例，然后传递给A。
 
没错，是这样。
 
通过参数化类A的方法，我们把类A与类B间的耦合转移了一部分到A的调用者那里。实际上总的耦合并没有消除，只是被分解了。但是程序设计中不可能完全不存在耦合，我们需要做的是”正确”，而不是”完美”。类A的耦合性降低了，使得我们在未来需求变更的时候，类A有更大的可能性不需要被修改，并且对功能的扩展更加友好，这就达成了我们的目标了。
基于上述做法，如果我们在未来扩展是派生出一个B的子类，override相关的方法，那么类A的代码基本是不需要修改的。
 
不过，问题是，假若A::OnMessageXX中，并不仅仅需要对类B发出消息，还需要对一系列相关的类B1，B2，B3等等发出消息呢？
 
哦，或许我们可以这样做：
 
void A::OnMessageXX(const std::list<B*>& lstBInstances)
{
         for (std::list<B*>::const_iterator itr = lstBInstances.begin();
                   itr != lstBInstances.end();
                   ++itr)
         {
                   (*itr)->DoSomething();
}
}
 
是的，上面这是一种做法，有一系列B的对象需要被通知到，所以我们可以用一个列表把他们串起来，然后在循环中通知他们去干活。不过这样做的前提是，这一系列B对象都是派生自一个公共基类B，有共通的接口；此外，我们需要在A的OnMessageXX被调用之前构造一个需要接受通知的B对象列表。
 
当A需要通知B，C，D等一系列没有公共接口的对象的时候，上面的这种做法就无法处理了。
 
对于B、C、D等需要由A来调用的类来说，它们需要在A通知它们的时候，做一些特定的事情。而又A则是在某些特定的时刻需要通知B、C、D。这样，我们可以把问题看成一个消息响应机制。
 
B、C、D可以在A的某些事件上注册一些回调函数，当事件发生时，A确保注册该事件的函数被调用到。
 
如下：
typedef void(callback*)();
class A {
public:
         enum EventIds {
         EVENT_MSG1,
         EVENT_MSG2,
};
void RegisterEvent(int nEventId, callback pfn);
private:
callback m_pfnCallback;
};
 
现在，B可以调用A::RegisterEvent注册一个事件，并传递一个函数指针给A。
当A中发生了注册的事件时，这个函数指针会被回调到。
不过这种简单的做法适应性很差：
1、  不能支持单个事件的多个callback (可能有很多类都需要注册该事件，并在事件发生时依次被回调)
2、  不能支持多个事件的同时存在
3、  回调函数没有参数’
 
针对问题1，2，我们可以使用一个事件映射解决问题，做法如下：
typedef int EventId;
typedef void (callback*)();
typedef std::list<callback> CallbackList;
typedef std::map<EventId, CallbackList> CallbackMap;
现在这个数据结构就能够支持多个event同时存在，且每个event都可以支持多个回调函数了。
 
但是这种用法依旧很不方便，如果类B想要注册A上的一个事件，他需要定义一个 callback类型的函数，并把这个函数的地址传递给A。问题是，往往我们希望类B的回调函数在被调用到的时候，对类B中的数据和状态进行修改，而一个单独的函数，若想获得/修改B中的状态，则必须要与类B紧密耦合。（通过获取全局对象，或者Singleton的方式）
这种紧密耦合引发我们的思考，能否在Callback中同时包含类B的指针与类B的成员函数。
 
答案是肯定的：泛型回调就可以做到这一点。关于泛型回调(Generic callback)的信息，在Herb [...]