先從23條規(guī)說起，大師在一開始先給出了為什么推崇非成員函數(shù)的理由：

• 從面向?qū)ο蟮慕嵌葋砜?，非成員函數(shù)更有利于數(shù)據(jù)的封裝。
  數(shù)據(jù)的封裝程度可以這樣理解：一個數(shù)據(jù)成員被越少的代碼訪問到，該成員的封裝程度就越高。我們可以進一步這樣理解：越少函數(shù)可以直接訪問一個數(shù)據(jù)成員，該成員的封裝程度就越高。
  如果還記得22課的內(nèi)容，就知道類的數(shù)據(jù)成員應(yīng)該定義為私有。如果這個前提成立，那么能夠訪問一個數(shù)據(jù)成員的函數(shù)便只能是該類的成員函數(shù)，或是友元函數(shù)。
  于是很容易得到上面的結(jié)論：為了更好的封裝數(shù)據(jù)，在可以完成相同功能的前提下，應(yīng)該優(yōu)先考慮使用非成員并且非友元函數(shù)。
  這里的“非成員并且非友元函數(shù)”是針對數(shù)據(jù)成員所在的類而言的，也就是說這個函數(shù)完全可以是其他類的成員，只要是不能直接訪問那個數(shù)據(jù)成員就可以。

• 從靈活性上來說，非成員函數(shù)更少編譯依賴(compilation dependency)，也就更利于類的擴展。
  先援引大師的例子來說明一下怎樣是編譯依賴：一個類可能有多個成員函數(shù)，可能有一個函數(shù)需要A.h，另外一個函數(shù)要包含B.h，那么在編譯這個類時就需要同時包含A.h和B.h，也就是說該類同時依賴兩個頭文件。
  如果我們使用的是非成員函數(shù)咧，這個時候就可以把這些依賴關(guān)系不同的函數(shù)分別寫在不同的頭文件中，有可能這個類在編譯時就不需要再依賴A.h或是B.h了。
  另外一點要注意的是在把這些非成員函數(shù)分散定義在不同頭文件中的同時，需要用namespace關(guān)鍵字把它們和需要訪問的類放在一起。(好歹有點關(guān)系，別不住在一起就翻臉不認(rèn)人了嘛……)
  //?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, 中)。
  如果有需要添加新的非成員函數(shù)，我們要做的只是在相同的名字空間中定義這些函數(shù)就可以，那個類絲毫不會被影響，也即所謂的易擴展性吧。
  對于類的用戶來說，這樣的實現(xiàn)方式(指用非成員函數(shù))就更加合理：
  因為作為類的用戶，需要擴展類的時候又不能去修改別人的類(版權(quán)？安全性？或者根本就沒有源碼？)，就算是通過繼承該類的方式也不能訪問父類的私有數(shù)據(jù)。