Effective C++条款22：设计与声明之（将成员变量声明为private）

一、不要把成员变量声明为private

统一性

• 如果成员变量不是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 readOnly;  //外部只读
    int readWrite; //外部可读可写
    int writeOnly; //外部只写
};

封装性

• 将成员变量隐藏在接口的背后，可以为“所有可能的实现”提供弹性
• 封装性也可以对成员变量进行保护

二、最好也不要把成员变量声明为protected

• protected的论点与上面的其实也十分类似

protected的封装性不一定有private好

• 条款23将会介绍到，成员变量的封装性与“成员变量的内容改变（改变就是指移除）时所破坏的代码数量成反比”。也就是说封装性越好，成员变量改变时破坏的代码就越少
  • 如果我们把成员变量声明为public，那么当我们把成员变量移除的时候，程序中很多的代码就会被破坏（封装性差，破坏性强）
  • 如果我们把成员变量声明为protected，那么当我们在基类中把这个成员变量移除的时候，那么很多使用到这个成员变量的派生类将会出错（封装性差，破坏性强）

• 因此，看起来，protected不一定比private的封装性好

三、总结

• 切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微性划分访问控制、允许约束条件获得保证，并提供class作者以充分的实现弹性
• protected并不比public更具封装性