多對多
下一個問題是，我們能夠在點擊一次重新載入按鈕之後做多個操作嗎？也就是讓信號和槽實現多對多的關系？
實際上，我們只需要利用一個普通的鏈表，就可以輕松實現這個功能了。比如，如下的實現：
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 類並不需要知道 Page 類。松耦合意味著更少的依賴；依賴越少，組件的可重用性也就越高。
當然，肯定需要有組件同時知道 Button 和 Page，從而完成對它們的連接。現在，我們的連接實際是用代碼描述的，如果我們不用代碼，而用數據描述連接呢？這麼一來，我們就有了松耦合的類，從而提高二者的可重用性。
新的連接模式
什麼樣的連接模式才算是非代碼描述呢？假如僅僅只有一種信號槽的簽名，例如 void (*signature)()，這並不能實現。使用散列表，將信號的名字映射到匹配的連接函數，將槽的名字映射到匹配的函數指針，這樣的一對字符串即可建立一個連接。
然而，這種實現其實包含一些“握手”協議。我們的確希望具有多種信號槽的簽名。在信號槽的簡短回答中我們提到，信號可以攜帶附加信息。這要求信號具有參數。我們並沒有處理成員函數與非成員函數的不同，這又是一種潛在的函數簽名的不同。我們還沒有決定，我們是直接將信號連接到槽函數上，還是連接到一個包裝器上。如果是包裝器，這個包裝器需要已經存在呢，還是我們在需要時自動創建呢？雖然底層思想很簡單，但是，真正的實現還需要很好的努力才行。似乎通過類名能夠創建對象是一種不錯的想法，這取決於你的實現方式，有時候甚至取決於你有沒有能力做出這種實現。將信號和槽放入散列表需要一種注冊機制。一旦有了這麼一種系統，前面所說的“有太多類了”的問題就得以解決了。你所需要做的就是維護這個散列表的鍵值，並且在需要的時候實例化類。
給信號槽添加這樣的能力將比我們前面所做的所有工作都困難得多。在由鍵值進行連接時，多數實現都會選擇放棄編譯期類型安全檢查，以滿足信號和槽的兼容。這樣的系統代價更高，但是其應用也遠遠高於自動信號槽連接。這樣的系統允許實例化外部的類，比如 Button 以及它的連接。所以，這樣的系統有很強大的能力，它能夠完成一個類的裝配、連接，並最終完成實例化操作，比如直接從資源描述文件中導出的一個對話框。既然它能夠憑借名字使函數可用，這就是一種腳本能力。如果你需要上面所說的種種特性，那麼，完成這麼一套系統絕對是值得的，你的信號槽系統也會從中受益，由數據去完成信號槽的連接。
對於不需要這種能力的實現則會忽略這部分特性。從這點看，這種實現就是“輕量級”的。對於一個需要這些特性的庫而言，完整地實現出來就是一個輕量級實現。這也是區別這些實現的方法之一。
本文出自 “豆子空間” 博客，請務必保留此出處http://devbean.blog.51cto.com/448512/424778
