(轉)

關于低耦合的消息傳遞，實現的方式有很多，哪種方法更好與具體的使用環境有關，本文使用試錯的方法，逐步探索達成這一目的具體方式，并理解實現方式背后的原因。

 

面向對象的系統當中，不可避免的有大量的類間消息傳遞的需求：一個類需要通知另一個或幾個類做些什么。

 

這種類間消息傳遞，簡單的說，就是調用其他類的方法。

如下：

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 Sutter的Exceptional C++ Style的35條中有詳細介紹。

 

一下比較簡單的泛型回調的定義如下：

class callbackbase {

public:

virtual void operator()() const {};

virtual ~callbackbase() = 0 {};

};

 

template <class T>

class callback : public callbackbase {

public:

typedef void (T::*Func)();

callback(T& t, Func func) : object(t), f(func) {}     // 綁定到實際對象

void operator() () const { (object->*f)(); }              // 調用回調函數

private:

T* object;

Func f;

};

 

有了這種泛型回調類，我們就可以將類B的實例與B的成員回調函數綁定在一起注冊到容器當中了，而不必再被如何在普通函數中修改B對象狀態的問題所困擾了。不過回調函數的參數問題依舊。如果想支持參數，我們不得不對每一種參數類型做一個不同的typedef，像上面定義的這樣 typedef void (T::*Func)();（如：typedef void (T::*Func)(int);）

一種解決方案是借助于Any（一種任意類型類）進行參數傳遞。

 

但是還有更完善的解決方案，不需要id號，也不需要泛型回調，Ogre采用Listener的方式實現的類間消息傳遞不僅可以支持單個類B對類A中某個事件的單次/多次注冊，也可以支持類B、C、D對同一個事件的注冊。而且可以完美的解決參數傳遞問題。

 

具體的方案如下：

class A {

public:

         class Listener {

         public:

                   virtual void OnMessageXX(int param1, float param2) = 0;

                   virtual void OnMessageYY(int param1, const std::string& param2) = 0;

};

 

void registerListener(Listener* obj) { m_lstListener.push_back(obj); }

void removeListener(Listener* obj)

{

         ListenerList::iterator itr = std::find(m_lstListener.begin(), m_lstListener.end(), obj);

         if (itr != m_lstListener.end())

                   m_lstListener.erase(itr);

}

 

private:

         typedef std::list<Listener*> ListenerList;

         ListenerList m_lstListeners;

};

 

有了以上定義，當類A收到某個消息XX之后，只需遍歷m_lstListeners列表，調用所有列表成員的OnMessageXX即可。

 

而所有注冊A的消息的類，都必須從A::Listener派生一個類，在它感興趣的消息處理函數中做出相應處理，而對不感興趣的消息，只需設為空函數即可。

 

一個簡單的類B的定義如下：

 

 

class B {

public:

         friend class BListener;

         class BListener : public A::Listener {

         public:

                   BListener(B* pBInstance) : m_pBInstance(pBInstance) {}

                   virtual void OnMessageXX(int param1, float param2)

{ m_pBInstance->DoSomething(); }

                   virtual void OnMessageYY(int param1, const std::string& param2) {}

         private:

                   B* m_pBInstance;

};

 

explicit B(A* pAInstance) : m_pAInstance(pAInstance)

{

m_pListener(new BListener(this));

m_pAInstance->registerListener(m_pListener);

}

         ~B() { m_pAInstance->removeListener(m_pListener); delete m_pListener; }

 

void DoSomething();

 

private:

         BListener* m_pListener;

}

 

類B在創建自身實例時，接受一個A的指針（這是合理的，因為類B需要監聽類A的消息，理應知道A的存在），并創建一個派生自A::Listener的監聽者對象，并把自身的指針傳遞給該對象，以使得該監聽者改變類B的狀態，而后類B將創建好的監聽者對象加入到A的監聽者列表中。

在B進行析構的時候，需要從A中刪除自己注冊的監聽者。而后將該對象釋放。

 

這種做法的好處：

1、  類B（以及類C等）對類A實現了信息隱藏，類A不再關注任何需要監聽它自身消息的其他類，只需關注其自身的狀態。從而減低了類A與其他與之關聯的類之間的耦合。（類A不必再費盡心機的去獲取B的指針，不管是通過全局變量，還是Singleton，還是參數，還是類成員變量，都不再需要了，A只關心在Listener中定義好的一組接口即可）而且，如果有必要類B可以對同一個消息注冊多次，且可以對同一消息有不同的反應（通過定義不同的BListener實現達到這一目的），只需在B不再需要監聽相關消息時將所注冊過的對象注銷掉即可。

2、  由于1中所述，類A的實現無需關心類B的實現，因此類A的邏輯中不需要包含任何類B的方法調用，從而，類A的cpp文件中，無需包含類B的頭文件，（可能還包括類C，D等等，此處類B指代需要根據類A狀態而做出動作的類）從而降低編譯時間，這是解耦合所帶來的附加好處。

3、  同樣是解耦合帶來的好處：因為無需關注類B等等其他類的實現，類A的代碼邏輯變得更加清晰，并且減少未來邏輯需求變更的改動所需要付出的代價（邏輯變更可能需要更改接口，需要增加狀態判斷，無論是調試時間還是編譯時間都是不可忽視的代價）。