1.为什么数据成员不能为公有(public)
开门见山，首先解释为什么数据成员不能为公有(public)，然后会说明为什么一样的约束也适用于保护(protected)成员。那么为什么我们不能把数据成员声明为公有?
语法一致性
试想一下，如果类的公有接口全部都是函数，用户就不用抓耳挠腮地思考到底要不要给一个成员后面加括号，弄清楚现在使用的到底是成员数据还是成员函数。如果我们把所有成员数据从公有接口拒之门外，类的接口显然会更加用户友好。
myObject.someStuff; // 成员数据 myObject.someStuff(); // 成员函数 //到底要用哪个?
访问权限的精确限制
如果数据成员是公有的，任何代码都可以对其进行读写，根本没有权限控制。如果我们希望实现各种读写权限的控制，就只能将其声明为私有，并使用成员函数执行不可读写、只读、可读写、甚至是只写的权限，因为唯一接触非公有成员数据的方法就是通过成员函数 (友元函数当然也可以，只不过在本文我们先只讨论成员函数，在后面的文章中会讲到友元函数与封装)。举一个简单的例子，实现上面的四种权限:
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; // 这个成员只写 };
封装
假设你正在给高速公路上的测速设备写一个应用，有一条需求规定要在每辆车经过时，计算出车的当前速度，并把这个速度放进一个数据集中。然后，使用这个数据集计算平均速度，即averageSpeed函数()。如下所示
class SpeedDataCollection{ ... public: void addValue(int speed); // 把当前测得的速度放进数据集中 double averageSpeed() const; // 利用数据集计算平均速度 .. };
对于averageSpeed函数()用两种实现思路：
(1).在类中增加一个表示移动平均(moving average)的数据成员，当averageSpeed()函数被调用，只用返回这个数据成员就可以了。但这种方法显然会导致SpeedDataCollection对象所需的内存增大，因为我们引入了新的移动平均成员，以及为了计算移动平均又需要引入当前所有数据的和以及数据的量。
(2).在被调用时，现场基于数据集计算这个平均速度。这种方法使用更少内存，只需要定义一个新的inline函数。但在被调用时需要现场计算，使用这个方法肯定要慢于第一种方法。
至于哪个更好，要看具体的环境。在内存较为有限的平台上，例如测速设备的嵌入式系统，而且平均速度不需要太频繁地被计算，例如在车流量较少的路上，第二种方法可能会更好。如果在车流量大的路上，平均速度则需要被频繁并且快速地计算，那么第一种方法可能会更好。
重点来了，如果希望把我们的应用做得用户友好，易于扩展和维护，例如可以针对不同的路况使用不同的实现方法，我们只需要把这个平均速度的数据成员封装起来，即把它声明为私有，对用户隐藏起来。需要时通过成员函数接触，不需要时直接使用另一种实现，就可以轻松地根据需求来回切换，最多也就只用重新编译一下。
如果不封装起来(即声明为公有)，如果那时要再改需求，恐怕难度就会非常巨大。因为我们不知道用户在哪以及如何使用了我们的数据成员，稍微改动便有可能导致整个程序的重写。也就是说公有成员即为未封装(unencapsulated)的成员，而未封装也就意味着代码的不可改动，尤其是对于经常被使用的类。
除此之外，将数据成员对用户隐藏起来(封装起来)还可以给各种各样的实现提供弹性。例如，可以通过成员函数来保证类不变量(class invariant)的限制条件被满足。因为只有成员函数能接触成员数据，对数据所做的改动也都只能遵循成员函数的规定。可能你会从public接触成员获得一时便利，但这背后牺牲了太多。
2.数据成员为什么也不能为保护(protected)
同样的约束也适用于保护(protected)的数据成员。上面提到的语法一致性和权限控制显然也成立，那么封装呢? 保护的成员是不是比公有成员有更好的封装呢?答案是不。
对于数据成员，它们的封装与因为它们的改动而导致可能失效的代码量成反比。假如我们的代码中有某些公有数据成员在后来的升级中被移除，那么有多少用户代码因此失效了呢？答：所有使用了这些数据成员的用户代码。这是一个不可测的数量，可能趋近于无穷大，也可能趋近于零，因此考虑到最坏的情况，公有数据成员是完全未封装的。
假如我们的代码中有某些保护数据成员在后来的升级中也被移除，那么有多少代码也因此失效了呢？答：所有使用了它们的子类。这又是一个不可测的量。因此，保护数据成员与公有数据成员是一样完全未封装的。在两种情况下，改动都有可能造成巨大数量的代码损坏。
最终结论：一旦我们在类中将某些数据成员声明为保护或公有，并且用户已经开始使用这些数据成员，我们将很难对这些数据成员再作出改动，否则可能就会导致巨大数量的代码被重写，重新测试，重新写文档。因此从封装的角度出发，数据成员的访问权限只有两个等级：私有(private)提供完全的封装、其它所有的(即protected和public)提供几乎零封装。
3.总结
(1).数据成员一定要声明为私有，这样能给用户提供语法一致性、精确的访问权限控制。保证类不变量的成立，各种功能实现的弹性。
(2).保护成员并不比公有成员更具封装性。
