好吧，以下是我們的計劃：我們首先要分析為什么數據成員不應該是公有的，然后繼續分析為什么數據成員也不能是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值擁有只寫級別訪問權
};
很有必要將訪問權管理得如此有條不紊，因為許多數據成員本應該被隱藏起來。并不是每個數據成員都需要一個取值器（getter）和一個賦值器（setter）。
還不是十分肯定？那么現在是時候使出殺手锏了：“封裝”。如果你通過程序實現了對一個數據成員的訪問，那么你就可以使用一次計算來代替這個數據成員，使用這一個類的人完全不會有所察覺。
請看下邊的示例，假設你正在為一種自動裝置編寫一個應用程序，這一裝置可以監視通過汽車的行駛速度，當一輛汽車通過時，這一應用程序就會計算出它的速度，然后將這一數值保存到一個小型數據庫中，其中保存著曾通過所有車輛的速度數據：
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++中封裝程度與代碼的健壯程度（這段代碼相關部分被修改時抵御破壞的能力）成正比。因此，數據成員的封裝程度與代碼的健壯程度也是成正比的。比如，當一個數據成員從類中移除時（可能你期望使用一次計算來代替，就像上文中的averageSoFar一樣），代碼是否會遭到破壞，將取決于封裝程度。
請考慮這個問題：假設我們有一個public數據成員，然后我們把它刪除了，那么將有多少的代碼將遭到破壞呢？我們說，所有使用它的客戶端代碼。這將是一個無法預知的巨大數字。公有數據成員就是這樣完全沒有封裝性的。但是繼續考慮：我們有一個protected數據成員，然后我們把它刪除了，此時將破壞多少代碼？我們說，所有使用它的派生類，這同樣是一個無法預知的巨大數字。由于在這兩種情況下，如果數據成員被更改了，那么將會為客戶帶來無法估量的損失，因此可以說protected數據成員與public的一樣沒有封裝性。這是違背直覺的，但是有經驗的庫實現者會告訴你，這是千真萬確的。一旦你聲明了一個public或protected的數據成員，然后客戶開始使用它，你就很難再對這一數據成員做出修改。因為這樣做會帶來太多的代碼重寫、重新測試重新編寫文檔和重新編譯等等工作。按封裝的理念來說，對于數據成員僅僅存在兩個層次的訪問權，那就是：private（可以提供封裝性）和非private（不提供封裝性）。
時刻牢記
l 要將數據成員聲明為私有的。這樣可以讓客戶端訪問數據時擁有一致的語義，提供有序的訪問控制，強制類保持一致性，為類作者提供更高的靈活性。
l protected并不會帶來比public更高的封裝性。