（一）為什麼不采用public成員變量
（1）首先，從語法一致性考慮，客戶唯一能訪問對象的方法就是通過成員函數，客戶不必考慮是否該記住使用小括號（）。
（2）其次，使用函數可以讓我們對成員變量的處理有更精確的控制。如果我們令成員變量為public，那麼每個人都可以讀寫它！
但如果我們以函數取得或設定其值，我們就可以實現出“不准訪問”、“只讀訪問”以及“讀寫訪問”，我們甚至可以實現“惟寫訪問”。
class AccessLevels {
public:
//成員noAccess無任何訪問動作，實現不准訪問！
int getReadOnlay() const {return readOnly;} //對這個數據成員設置為只讀訪問！
void setReadWrite(int value){readWrite = value;} //這個函數設置該數據成員可寫訪問！
int getReadWrite()const {return readWrite;} //這個函數設置該數據成員可讀訪問！
void setWriteOnly(int value){writeOnly = value;} //這個函數設置該數據成員惟寫訪問！
private:
int noAccess;
int readOnly;
int readWrite;
int writeOnly;
};
像這樣細微地劃分訪問控制頗有必要，因為許多成員變量應該被隱藏起來。每個成員變量都需要一個getter函數和setter函數畢竟罕見。
（3）最後，還有封裝性。如果通過函數訪問成員變量，日後可改以某個計算替換這個成員變量，客戶不會知道class內部實現已經起了變化。
成員變量隱藏在函數接口的背後，可以為“所有可能的實現”提供彈性。例如這可使得成員變量被讀或被寫時輕松通知其他對象、可以驗證class的約束條件及函數的前提和事後狀態、可以在多線程環境中執行同步控制。。。等等。
封裝性非常重要。如果對客戶隱藏成員變量（也就是）封裝，保留了日後變更實現的權力。public意味著不封裝，不封裝意味著不可改變。
protected成員變量就像public成員變量一樣缺乏封裝性：成員變量的封裝性與“成員變量的內容改變時所破壞的代碼數量”成反比，假設一個public成員變量，我們取消了它。所有使用它的客戶碼都會被破壞，那是一個不可知的大量。所以public成員函數完全沒有封裝性。假設一個protected成員變量，我們取消了它，所有使用它的derived classes都會被破壞，往往也是一個不可知的大量。
請記住：
（1）切記將成員變量聲明為private。這可賦予客戶訪問數據的一致性，可細微劃分訪問控制，允諾約束條件獲得保證，並提供class作者以充分的實現彈性。
（2）protected並不比public更具封裝性。
