多對多

下一個問題是，我們能夠在點擊一次重新載入按鈕之后做多個操作嗎？也就是讓信號和槽實現多對多的關系？

實際上，我們只需要利用一個普通的鏈表，就可以輕松實現這個功能了。比如，如下的實現：

class MultiAction : public AbstractAction// ...an action that is composed of zero or more other actions;// executing it is really executing each of the sub-actions { public:// ...virtual void execute(); private:std::vector<AbstractAction*> actionList_;// ...or any reasonable collection machinery };void MultiAction::execute() {// call execute() on each action in actionList_std::for_each( actionList_.begin(),actionList_.end(),boost::bind(&AbstractAction::execute, _1) ); }

這就是其中的一種實現。不要覺得這種實現看上去沒什么水平，實際上我們發現這就是一種相當簡潔的方法。同時，不要糾結于我們代碼中的 std:: 和 boost:: 這些命名空間，你完全可以用另外的類，強調一下，這只是一種可能的實現。現在，我們的一個動作可以連接多個 button 了，當然，也可以是別的 Action 的使用者。現在，我們有了一個多對多的機制。通過將 AbstractAction* 替換成 boost::shared_ptr<AbstractAction>，可以解決 AbstractAction 的歸屬問題，同時保持原有的多對多的關系。

這會有很多的類！

如果你在實際項目中使用上面的機制，很多就會發現，我們必須為每一個 action 定義一個類，這將不可避免地引起類爆炸。至今為止，我們前面所說的所有實現都存在這個問題。不過，我們之后將著重討論這個問題，現在先不要糾結在這里啦！

特化！特化！

當我們開始工作的時候，我們通過將每一個 button 賦予不同的 action，實現 Button 類的重用。這實際是一種特化。然而，我們的問題是，action 的特化被放在了固定的類層次中，在這里就是這些 Button 類。這意味著，我們的 action 很難被更大規模的重用，因為每一個 action 實際都是與 Button 類綁定的。那么，我們換個思路，能不能將這種特化放到信號與槽連接的時候進行呢？這樣，action 和 button 這兩者都不必進行特化了。

函數對象

將一個類的函數進行一定曾度的封裝，這個思想相當有用。實際上，我們的 Action 類的存在，就是將 execute() 這個函數進行封裝，其他別無用處。這在 C++ 里面還是比較普遍的，很多時候我們用 ++ 的特性重新封裝函數，讓類的行為看起來就像函數一樣。例如，我們重載 operator() 運算符，就可以讓類看起來很像一個函數：

class AbstractAction { public:virtual void operator()() = 0; };// using an action (given AbstractAction& action) action();

這樣，我們的類看起來很像函數。前面代碼中的 for_each 也得做相應的改變：

// previously std::for_each( actionList_.begin(),actionList_.end(),boost::bind(&AbstractAction::execute, _1) ); // now std::for_each( actionList_.begin(),actionList_.end(),boost::bind(&AbstractAction::operator(), _1) );

現在，我們的 Button::clicked() 函數的實現有了更多的選擇：

// previously action_->execute();// option 1: use the dereferenced pointer like a function (*action_)();// option 2: call the function by its new name action_->operator()();

看起來很麻煩，值得這樣做嗎？

下面我們來試著解釋一下信號和槽的目的。看上去，重寫 operator() 運算符有些過分，并不值得我們去這么做。但是，要知道，在某些問題上，你提供的可用的解決方案越多，越有利于我們編寫更簡潔的代碼。通過對一些類進行規范，就像我們要讓函數對象看起來更像函數，我們可以讓它們在某些環境下更適合重用。在使用模板編程，或者是 Boost.Function，bind 或者是模板元編程的情形下，這一點尤為重要。

這是對無需更多特化建立信號槽連接重要性的部分回答。模板就提供了這樣一種機制，讓添加了特化參數的代碼并不那么難地被特化，正如我們的函數對象那樣。而模板的特化對于使用者而言是透明的。

松耦合

現在，讓我們回顧一下我們之前的種種做法。

我們執著地尋求一種能夠在同一個地方調用不同函數的方法，這實際上是 C++ 內置的功能之一，通過 virtual 關鍵字，當然，我們也可以使用函數指針實現。當我們需要調用的函數沒有一個合適的簽名，我們將它包裝成一個類。我們已經演示了如何在同一地方調用多個函數，至少我們知道有這么一種方法（但這并不是在編譯期完成的）。我們實現了讓“信號發送”能夠被若干個不同的“槽”監聽。

不過，我們的系統的確沒有什么非常與眾不同的地方。我們來仔細審核一下我們的系統，它真正不同的是：

• 定義了兩個不同的術語：“信號”和“槽”；
• 在一個調用點（信號）與零個或者多個回調（槽）相連；
• 連接的焦點從提供者處移開，更多地轉向消費者（也就是說，Button 并不需要知道如何做是正確的，而是由回調函數去告知 Button，你需要調用我）。

但是，這樣的系統還遠達不到松耦合的關系。Button 類并不需要知道 Page 類。松耦合意味著更少的依賴；依賴越少，組件的可重用性也就越高。

當然，肯定需要有組件同時知道 Button 和 Page，從而完成對它們的連接。現在，我們的連接實際是用代碼描述的，如果我們不用代碼，而用數據描述連接呢？這么一來，我們就有了松耦合的類，從而提高二者的可重用性。

新的連接模式

什么樣的連接模式才算是非代碼描述呢？假如僅僅只有一種信號槽的簽名，例如 void (*signature)()，這并不能實現。使用散列表，將信號的名字映射到匹配的連接函數，將槽的名字映射到匹配的函數指針，這樣的一對字符串即可建立一個連接。

然而，這種實現其實包含一些“握手”協議。我們的確希望具有多種信號槽的簽名。在信號槽的簡短回答中我們提到，信號可以攜帶附加信息。這要求信號具有參數。我們并沒有處理成員函數與非成員函數的不同，這又是一種潛在的函數簽名的不同。我們還沒有決定，我們是直接將信號連接到槽函數上，還是連接到一個包裝器上。如果是包裝器，這個包裝器需要已經存在呢，還是我們在需要時自動創建呢？雖然底層思想很簡單，但是，真正的實現還需要很好的努力才行。似乎通過類名能夠創建對象是一種不錯的想法，這取決于你的實現方式，有時候甚至取決于你有沒有能力做出這種實現。將信號和槽放入散列表需要一種注冊機制。一旦有了這么一種系統，前面所說的“有太多類了”的問題就得以解決了。你所需要做的就是維護這個散列表的鍵值，并且在需要的時候實例化類。

給信號槽添加這樣的能力將比我們前面所做的所有工作都困難得多。在由鍵值進行連接時，多數實現都會選擇放棄編譯期類型安全檢查，以滿足信號和槽的兼容。這樣的系統代價更高，但是其應用也遠遠高于自動信號槽連接。這樣的系統允許實例化外部的類，比如 Button 以及它的連接。所以，這樣的系統有很強大的能力，它能夠完成一個類的裝配、連接，并最終完成實例化操作，比如直接從資源描述文件中導出的一個對話框。既然它能夠憑借名字使函數可用，這就是一種腳本能力。如果你需要上面所說的種種特性，那么，完成這么一套系統絕對是值得的，你的信號槽系統也會從中受益，由數據去完成信號槽的連接。

對于不需要這種能力的實現則會忽略這部分特性。從這點看，這種實現就是“輕量級”的。對于一個需要這些特性的庫而言，完整地實現出來就是一個輕量級實現。這也是區別這些實現的方法之一。

本文轉自 FinderCheng 51CTO博客，原文鏈接：?

http://blog.51cto.com/devbean/424778

總結

以上是生活随笔為你收集整理的深入理解信号槽（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。