条款22:将成员变量声明为private

条款22:将成员变量声明为private
        (Declare data members private.)

内容:
    首先我们讨论一下成员变量声明为public的情况,我们先从语法一致性角度来分析,如果成员变量不是public,
那么客户访问这些变量唯一的方法只能是通过访问成员函数,由于这个时候public接口内只有函数,我们的客户就
不需要在打算访问class成员时迷惑地试着记住是否该使用小括号(每个方法调用都会有括号),因为客户调用的只
能是函数,每样别的形式,在客户使用你的class,这样就节省客户使用你的class时间(他/她省去了这些思考的时
间).
    呵呵,上述的一致性的理由可能不会另你信服,那我们从另一个角度来描述这样做的理由:将成员变量说明为
private可以控制对成员变量的访问控制属性(read-only,write-only,read-write-only).我们来举个例子来说明
比较形象一点,这里我们有个Person类:
    class Person{
    public:
        Person(const string& name,unsigned char age,const string& address)
        :name_(name),age_(age),address_(address){}
        string getName()const{
            return name_;
        }
        string setAddress(string address){
            address_ = address;
        }
        void setAge(unsigned char age){
            age_ = age;
        }
        unsigned char getAge()const{
            return age_;
        }
    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更具封装性.