为什么不采用public成员变量呢？
1、为保持语法一致性
如果成员变量不是public，客户唯一能够访问对象的办法就是通过成员函数。
如果public接口内的每样东西都是函数，客户就不需要在打算访问class成员时迷惑地试着记住是否该使用小括号（圆括号）。
2、使用函数可以让你对成员变量的处理有更精确的控制
如果你令成员变量为public，每个人都可以读写它，但如果你以函数取得或设定其值，你就可以实现出“不准访问”、“只读访问”以及“读写访问”，甚至还有唯写访问：
class AccessLevels {
public:
...
int getReadOnly() const {return readOnly;}
void setReadWrite(int value) {readWrite = value;}
int getReadWrite() const {return readWrite;}
int setWriteOnly(int value) {writeOnly = value;}
private:
int noAccess;
int readOnly;
int readWrite;
int writeOnly;
}如此细微地划分访问控制颇有必要，因为许多成员变量应该被隐藏起来。
3、封装性
如果你通过函数访问成员变量，日后可改以某个计算替换这个成员变量，而class用户一点也不会知道class的内部已经起了变化。通过成员函数来访问某个数据量，你得以替换不同的实现方式，客户最多只需要重新编译。
如果你对客户隐藏成员变量，你可以确保class的约束条件总是会获得维护，因为只有成员函数可以影响他们。犹有进者，你保留了日后变更实现的权利。
protected成员变量的论点十分类似，实际上它和public成员变量的论点相同，虽然或许最初看起来不是一回事。“语法一致性”和“细微划分之访问控制”等理由显然也适用于protected数据，就像对public一样适用。
但封装呢？protected成员变量的封装性是不是高于public成员变量？某些东西的封装性与“当其内容改变时可能造成的代码破坏量”成反比。所谓改变，也许是从class中移除它。
假设我们有一个public成员变量，而最终取消了它。多少代码可能会被破坏呢？实际上所有使用它的客户码都会被破坏，而那是一个不可知的大量，因此public成员变量完全没有封装性。假设我们有一个protected成员变量，而我们最终取消了它，有多少代码被破坏？所有使用它的derived classes都会被破坏，那往往也是个不可知的大量。因此protected成员变量就像public成员变量一样缺乏封装性。一旦你将一个成员变量声明为public或protected而客户开始使用它，就很难改变那个成员变量所涉及的一切。太多代码需要重写，重新测试，重新编写文档，重新编译。
从封装的角度观之，其实只有两种访问权限：private（提供封装）和其他（不提供封装）。