【轉】http://m.shnenglu.com/tiandejian/archive/2007/06/06/ec_22.html
第22條： 盡量將數據成員聲明為私有的
好吧，直截了當的說，在這一條中：我們首先要分析為什么數據成員不應該是公有的，與此同時，繼續分析為什么數據成員也不能是 protected 的。然后就引出本條款的結論：數據成員必須是私有的。
那么，數據成員為什么不能 是 public 的 ？
讓我們從討論語義的一致性問題開始（另請參見第 18 條）。如果數據成員不是公有的，那么客戶端程序員要想訪問對象就只剩下成員函數一種方法。如果公有接口中所有的東西都是函數，那么客戶端程序員在期望訪問類成員時，由于一切都是函數，所以就可以任意使用，而不用擔心是否需要使用括號。在整個過程中，這樣做可以讓你節省大量躊躇不定的時間。
但是也許你會發現，并沒有強制規定來要求語義的一致性。那么你是否會發現：使用函數可以讓你更精確地控制數據成員的訪問權？如果把一個數據成員定義為 public 的，那么每個人對其都擁有“只讀”的訪問權，但是如果你使用函數來為數據成員賦值，或者獲取數據成員的值，那么你可以將其實現為“禁止訪問”、“只讀”以及“可讀可寫”幾種級別的訪問權；嘿，如果需要，你甚至可以將其實現為“只寫”的訪問權：
class AccessLevels {
public:
...
int getReadOnly() const { return readOnly; }
void setReadWrite(int value) { readWrite = value; }
int getReadWrite() const { return readWrite; }
void setWriteOnly(int value) { writeOnly = value; }
private:
int noAccess; // 禁止訪問此 int 值
int readOnly; // 此 int 值擁有只讀級別訪問權
int readWrite; // 此 int 值擁有可讀可寫級別訪問權
int writeOnly; // 此 int 值擁有只寫級別訪問權
};
很有必要將訪問權管理得如此有條不紊，因為許多數據成員本應該被隱藏起來。并不是每個數據成員都需要一個賦值器和一個取值器。
還不是十分肯定？那么現在是時候使出殺手锏了：“封裝”。如果你通過程序實現了對一個數據成員的訪問，那么你就可以使用一次計算來代替這個數據成員，使用這一個類的人完全不會有所察覺。
請看下邊的示例，假設你正在為一種自動裝置編寫一個應用程序，這一裝置可以監視通過汽車的行駛速度，當一輛汽車通過時，這一應用程序就會計算出它的速度，然后將這一數值保存到一個小型數據庫中，其中保存著曾通過所有車輛的速度數據：
class SpeedDataCollection {
...
public:
void addValue(int speed); // 添加新的數據值
double averageSoFar() const; // 返回速度的平均值
...
};
現在請注意成員函數 averageSoFar 的具體實現問題。一種實現方法是：為類添加一個數據成員，讓它保存速度的平均值，隨數據庫的改動更新這一成員的數值。當調用 averageSoFar 時，它僅僅返回這一數據成員的值。另一種做法是：在每次調用 averageSoFar 時都計算出這一平均值，此時需要檢查數據庫中所有的數據值。
因為第一種手段（保存即時更新的平均值）中，你需要為保存即時更新平均值、累計總和以及數據的個數這幾種數據成員分配空間，因此這一方法使得 SpeedDataCollection 對象都變得更大一些。然而， averageSoFar 卻十分的高效。可以把它寫成一個內聯函數（參見第 30 條），所做的僅僅是返回這一即時更新的。相反的是，在需要時進行計算會使 averageSoFar 變慢，但是 SpeedDataCollection 對象的體積更小。
二者孰優孰劣，誰又能斷定呢？在一個內存較為局促的機器（比如移動嵌入式設備）上，并且該應用程序不會頻繁的調用平均值，那么在需要時計算的方案就更為優秀。相反地，在平均值需要頻繁使用，速度是程序的關鍵，內存不是問題的情況下，則更應采用保存一個即時平均值的方案。最重要的一點是，在通過成員函數訪問平均值時（也就是“封裝”），你可以交替使用這兩種實現方案（當然，你可能還會想到其它重要的問題），客戶端程序員頂多要做的一件事就是重新編譯一下代碼。（即使這一點所帶來的不方便也可以排除。參見第 31 條中介紹的技術。）
將數據成員隱藏在函數接口的背后可以使得任意種類的實現方法更加靈活多變。比如說，這樣做可以非常容易地做到下面幾件事情：提醒其它對象自己的數據成員是在被讀還是寫，驗證類的恒定性和函數運算的狀態，在多線程系統下進行同步操作，等等。如果讓 Delphi 或 C# 的程序員使用 C++ ，他們會發現 C++ 這一特性與這些語言中的“屬性”很相像，只是 C++ 中需要一對括號。
封裝是 C++ 的一個博大精深的特性。如果你對客戶端程序員隱藏了數據成員的話（也就是將數據成員封裝起來），你就可以確保類永遠保持一致性，這是因為只有成員函數可以影響到數據成員，你保留了在以后改變具體實現方法的權利。如果你不將這些方法隱藏起來，那么你很快就會發現，即使你擁有類的源代碼，你也只能在很小的范圍內修改其中公用的部分，因為這樣做會破壞許多客戶端代碼。公用就意味著未封裝，同時從實用角度講，未封裝就意味著無法更改，較為廣泛應用的類更甚之。然而廣泛應用的類最需要使用封裝，因為它們可以從“具體實現可以不斷改良”這一點上獲得最大程度的收益。
上面的分析對于 protected 數據成員也適用。盡管二者乍看上去有一定的區別，實際上它們是完全一致的。在使用 public 數據成員時，我們分析了語意一致性問題和訪問權條理性問題，這一分析過程對于使用 protected 數據同樣適用。但還有一個問題——封裝。 protected 數據成員不是比 public 的更具有封裝性嗎？從實用角度講，你會得到一個令人吃驚的答案：不是。
第 23 條中將介紹這一問題： C++ 中封裝程度與代碼的健壯程度（這段代碼相關部分被修改時，抵御自身遭到破壞的能力）成正比。所以我們可以得出下面的結論：數據成員的封裝程度與代碼的健壯程度也是成正比的。代碼遭到的破壞可能是：將某個數據成員從類中移除。（可能你期望使用一次計算來代替，就像上文中的 average 一樣。）
請考慮這個問題：假設我們有一個 public 數據成員，然后我們把它刪除了，那么將有多少的代碼將遭到破壞呢？我們說，所有使用它的客戶端代碼。這將是一個。公有數據成員就是這樣完全沒有封裝性的。但是繼續考慮：我們有一個 protected 數據成員，然后我們把它刪除了，此時將破壞多少代碼？我們說，所有使用它的派生類，這同樣是一個無法預知的巨大數字。由于在這兩種情況下，如果數據成員被更改了，那么將會為客戶端程序員帶來無法估量的損失，因此可以說 protected 數據成員與 public 的一樣沒有封裝性。這是違背直覺的，但是有經驗的類實現者會告訴你，這是千真萬確的。一旦你聲明了一個 public 或 protected 的數據成員，然后客戶端程序員開始使用它，你就很難再對這一數據成員做出修改。因為這樣做會帶來太多的代碼重寫、重新測試重新編寫文檔和重新翻譯等等工作。按封裝的理念來說，對于數據成員僅僅存在兩個層次的訪問權，那就是： private （可以提供封裝性）和其它的一切（不提供封裝性）。
銘記在心
l 要將數據成員聲明為私有的。這樣可以讓客戶端訪問數據時擁有一致的語義，提供有條不紊的訪問控制，強制類符合一致性，為類作者提供更高的靈活性。
l protected 并不會帶來比 public 更高的封裝性。