條款22:將成員變數宣告為private
(declare data members private.)
內容:首先我們討論一下成員變數宣告為public的情況,我們先從語法一致性角度來分析,如果成員變數不是public,
那麼客戶訪問這些變數唯一的方法只能是通過訪問成員函式,由於這個時候public介面內只有函式,我們的客戶就
不需要在打算訪問class成員時迷惑地試著記住是否該使用小括號(每個方法呼叫都會有括號),因為客戶呼叫的只
能是函式,每樣別的形式,在客戶使用你的class,這樣就節省客戶使用你的class時間(他/她省去了這些思考的時
間).呵呵,上述的一致性的理由可能不會另你信服,那我們從另乙個角度來描述這樣做的理由:將成員變數說明為
private可以控制對成員變數的訪問控制屬性(read-only,write-only,read-write-only).我們來舉個例子來說明
比較形象一點,這裡我們有個person類:
class person
string getname()const
string setaddress(string address)
void setage(unsigned char age)
unsigned char getage()const
private:
string name_; //read-only
unsigned char age_; //write-read-only
string address_; //write-only
};看了上面這個例子,是不是覺得這樣做是有道理的,有些認可我的觀點了?為了讓對這個觀點確信不疑,我不得不
拿出我的'絕招'了:封裝性.假如你宣告成員變數為public,那麼任何物件都可以訪問它們了,這樣毫無封裝性可言,給
**的維護帶來了很大的困難(成員變數值的改變可能是任何擁有可以隨意修改它們值許可權的地方).讓客戶通過成員
函式訪問(而不是通過直接訪問變數),這樣另一方面也隱藏了實現,變數成員的任何變動都不會影響介面(對外暴露的
成員函式),客戶不需要關心介面內部對成員變數到底做了些什麼.
不能將成員變數宣告在protected內的論點也十分相似."語法一致性"和"細微劃分之訪問控制"等理由也適合於protected
資料,但是對於封裝性呢?protected成員變數封裝性是不是高過public成員變數?這裡的答案卻不是肯定的.
封裝性到底跟什麼有直接或者間接的關係呢?我們將在條款23中談到,成員變數的封裝性與"當其內容改變時可能
造成的**破壞量"成反比,這裡的成員變數改變也學就是從class中移除它.
現在假設我們已經有了乙個public成員變數,現在我們取消它,我們的**將有多少被破壞呢?所有使用它的**
都會被破壞,那是乙個不可知的大量的修改工作;假設我們有乙個protected成員變數,現在移除它,那麼所有它的derived
classes都會被破壞,同樣也是乙個不可知的大量的修改過程,由此這裡我們得出乙個結論:protectecd成員變數就像
public成員變數一樣缺乏封裝性.因為在這兩種情況下,一旦成員變數被修改,都會有不可預知的大量**將會被破壞.
好了,this topic is over!
請記住:
■ 切記將成員變數宣告為private.這可賦予客戶訪問資料的一致性,可細微劃分訪問控制,允諾約束條件獲得保證,
並提供class作者以充分的實現彈性.
■ protected並不比public更具封裝性.
條款22 將成員變數宣告為private
假設有乙個public成員變數，當取消它時 所有使用它的客戶 都會被破壞。因此public成員變數完全沒有封裝性。假設有乙個protected成員變數，當取消它時 所有使用它的derived classes都會被破壞。所有反對public成員變數的論點同樣適用於protected。其封裝性並不比pu...
條款22 將成員變數宣告為private
為什麼要將成員變數宣告為private 1.為了語法的一致性 訪問class成員變數時不需要使用小括號，訪問class成員函式時需要使用小括號。2.使用函式可以讓你對成員變數的處理有更精準的控制 可以實現 唯讀 只寫 3.最重要的，是為了封裝。封裝的好處 可以為所有可能的實現提供彈性 如新增通知 驗...
條款22 將成員變數宣告為private
將所有成員變數都宣告private，剩下的成員就是成員函式了。那麼外部訪問時都得要帶括號，因為只可以訪問成員函式。如果令成員變數為public，每個人都可以讀寫它，但是如果你以函式取得或設定其值，你就可以實現出 不可訪問 唯讀訪問 讀寫訪問 protected 和public其實是一樣的，無論從一致...