[原創文章歡迎轉載，但請保留作者信息]
Justin 于 2009-12-23
先從23條規說起，大師在一開始先給出了為什么推崇非成員函數的理由：
-
從面向對象的角度來看，非成員函數更有利于數據的封裝。
數據的封裝程度可以這樣理解：一個數據成員被越少的代碼訪問到，該成員的封裝程度就越高。我們可以進一步這樣理解：越少函數可以直接訪問一個數據成員，該成員的封裝程度就越高。
如果還記得22課的內容，就知道類的數據成員應該定義為私有。如果這個前提成立，那么能夠訪問一個數據成員的函數便只能是該類的成員函數，或是友元函數。
于是很容易得到上面的結論：為了更好的封裝數據，在可以完成相同功能的前提下，應該優先考慮使用非成員并且非友元函數。
這里的“非成員并且非友元函數”是針對數據成員所在的類而言的，也就是說這個函數完全可以是其他類的成員，只要是不能直接訪問那個數據成員就可以。
-
從靈活性上來說，非成員函數更少編譯依賴(compilation dependency)，也就更利于類的擴展。
先援引大師的例子來說明一下怎樣是編譯依賴：一個類可能有多個成員函數，可能有一個函數需要A.h，另外一個函數要包含B.h，那么在編譯這個類時就需要同時包含A.h和B.h，也就是說該類同時依賴兩個頭文件。
如果我們使用的是非成員函數咧，這個時候就可以把這些依賴關系不同的函數分別寫在不同的頭文件中，有可能這個類在編譯時就不需要再依賴A.h或是B.h了。
另外一點要注意的是在把這些非成員函數分散定義在不同頭文件中的同時，需要用namespace關鍵字把它們和需要訪問的類放在一起。(好歹有點關系，別不住在一起就翻臉不認人了嘛……)
//?code?in?class_a.h
namespace??AllAboutClassA??{
???class??ClassA??{?//?..};
???//?..
}
//?code?in?utility_1.h
//?..
namespace??AllAboutClassA??{
???void??WrapperFunction_1()?{?//?..};
???//?..
}
//?..
//?code?in?utility_2.h
//?..
namespace??AllAboutClassA??{
???void??WrapperFunction_2()?{?//?..};
???//?..
}
//?..
這樣一來，雖然這些非成員和類不“住在”一個頭文件里，它們的“心”還是在一起的(在同一個名字空間, namespace, 中)。
如果有需要添加新的非成員函數，我們要做的只是在相同的名字空間中定義這些函數就可以，那個類絲毫不會被影響，也即所謂的易擴展性吧。
對于類的用戶來說，這樣的實現方式(指用非成員函數)就更加合理：
因為作為類的用戶，需要擴展類的時候又不能去修改別人的類(版權？安全性？或者根本就沒有源碼？)，就算是通過繼承該類的方式也不能訪問父類的私有數據。
接下來看看第24條，說的也是非成員非友元函數。Item24的標題比較不直白：”當類型轉換需要應用在所有參數的時候，函數應該是非成員函數“，讀下來覺得還是無法理解。【以下是自己對此條軍規的解讀，有待再次拜讀時完善】代碼在書上，很好很明了。不抄代碼了，嘗試總結一下：
如果運算符函數的參數有可能發生類型轉換，該函數就應該定義為非成員非友元函數。原因是：
此類函數幾乎總是隱性調用的：
result?=?oneHalf?*?2;?//?*?is?invoked?implicitly
而鮮少有下面的顯性調用：
result?=?oneHalf.operator*(2);?//?*?is?invoked?explicitly
當操作數對象的類型沒有定義這一運算符函數時(或是沒有定義隱性構造函數, implicit constructor時)，就會出錯。
如果不明白，就去看例程吧……