Effective C++：條款22：將成員變數聲明為private

標籤：彈性   set   content   round   實現   一個   客戶   ssl   read   

（一）為什麼不採用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更具封裝性。

Effective C++：條款22：將成員變數聲明為private