我一向是不太喜歡給一些東西強加上個名字。但為了隨波逐流,我還是這樣做了。
在我們的游戲開發中,通常會遇到兩個模塊之間的通信。 回調估計是最常用的方式了。 回調的設計思想很簡單,就是兩個對象相互注冊,然后在需要的時候調用對方的函數。
如下:
這樣,當A執行自己的某些動作的時候,就調用B的函數,這樣B就會進行自己的更新或是一些處理。
但是,由于兩個對象的直接回調,導致了許多不方便之處。特別是當A和B的功能需要擴展的時候。例如:現在A在執行過程中,需要調用B中其它的功能函數。這時候就不得不修改A和B的接口。然后大家都重新編譯,連接,執行。
于是,我們就會想會不會有一種更好的方法來解決這一問題。 大家可以想想,WINDOWS中的通信機制:通過解析消息類型來進行處理。是的,消息回調的好處就是方便擴展。 當然我們這里要講的不是像WINDOWS中那樣的消息通信機制,對于我們來說,那種做法過繁瑣。
假設現在是想讓A通知B一些事情。那么,我們可以把B的void DoB();函數作一點點修改:
同理,當B要通知A的時候,也這樣做就行了。
但是,這樣也很麻煩,關鍵在于,如果現在寫類A的人并不知道類B的人會怎么寫,或者說,類B不知道什么時候要寫。另外,如果我們強制類B要實現這樣的接口,會有點不現實。
此時,我們決定使用一個中間對象來連接他們。
這就是我們傳說中的監聽器了。 在OGRE或是一些廣泛采用面向對象思想的源程序中,隨處可見這樣的模式。
還是假設是A需要通知B一些事情。那么,可以在A中注冊這個對象,然后調用它的方法就可以了。
而我們在實現B的時候,除了要實現B自己的東西以外,還需要將ICallBack派生并實現 void Do(int Msg)函數;
這樣,雙方便很自然地通了信。而寫類A的人根本不需要理會類B的人會怎么寫,也不用去管類B會是什么樣的類名。只要告訴寫類B的人,你需要實現這個Callback接口,并且對應的MsgID是干什么用的就OK了。
也許初初的一看,這是吃力不討好的工作。畢竟一個寫A的人,會去想那么多事情。 而一個寫B的人,還要去實現一個Callback類。但是,從可擴展性,和降低耦合上來講,的確會起不少的作用。
而上面的void Do(int MsgID);函數,可以做得更強大一點。
寫成void Do(void* pData); 而這個pData怎么使用,就要看A和B通信的具體內容了。
我正盡力地試著把自己想要說的講清楚,謝謝!