Item 22: 将数据成员声明为 private
好了，先公布一下计划。首先，我们将看看为什么数据成员不应该声明为 public。然后，我们将看到所有反对 public 数据成员的理由同样适用于 protected 数据成员。这就导出了数据成员应该是 private 的结论，至此，我们就结束了。
那么，public 数据成员，为什么不呢？
我们从先从语法一致性开始（参见 Item 18）。如果数据成员不是 public 的，客户访问一个对象的唯一方法就是通过成员函数。如果在 public 接口中的每件东西都是一个函数，客户就不必绞尽脑汁试图记住当他们要访问一个类的成员时是否需要使用圆括号。他们只要使用就可以了，因为每件东西都是一个函数。一生坚持这一方针，能节省很多挠头的时间。
但是也许你不认为一致性的理由是强制性的。使用函数可以让你更加精确地控制成员的可存取性的事实又怎么样呢？如果你让一个数据成员为 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; // no access to this int
int readOnly; // read-only access to this int
int readWrite; // read-write access to this int
int writeOnly; // write-only access to this int
};
这种条分缕析的访问控制很重要，因为多数数据成员需要被隐藏。每一个数据成员都需要一个 getter 和 setter 的情况是很罕见的。
还不相信吗？那么该拿出一门重炮了：封装。如果你通过一个函数实现对数据成员的访问，你可以在以后用一个计算来替换这个数据成员，使用你的类的人不会有任何察觉。
例如，假设你为一个监视通过的汽车的速度的自动设备写一个应用程序。每通过一辆汽车，它的速度就被计算，而且那个值要加入到迄今为止收集到的所有速度数据的集合中：
class SpeedDataCollection {
...
public:
void addValue(int speed); // add a new data value
double averageSoFar() const; // return average speed
...
};
现在考虑成员函数 averageSoFar 的实现：实现它的办法之一是在类中用一个数据成员来实时变化迄今为止收集到的所有速度数据的平均值。无论何时 averageSoFar 被调用，它只是返回那个数据成员的值。另一个不同的方法是在每次调用 averageSoFar 时重新计算它的值，通过分析集合中每一个数据值它能做成这些事情。
第一种方法（保持一个实时变化的值）使每一个 SpeedDataCollection 对象都比较大，因为你必须为持有实时变化的平均值，累计的和以及数据点的数量分配空间。可是，averageSoFar 能实现得非常高效，它仅仅是一个返回实时变化的平均值的 inline 函数（参见 Item 30）。反过来，无论何时被请求都要计算平均值使得 averageSoFar 的运行比较慢，但是每一个 SpeedDataCollection 对象都比较小。
谁能说哪一个最好？在内存非常紧张的机器（例如，一个嵌入式道旁设备）上，以及在一个很少需要平均值的应用程序中，每次都计算平均值可能是较好的解决方案。在一个频繁需要平均值的应用程序中，速度是基本的要求，而且内存不成问题，保持一个实时变化的平均值更为可取。这里的重点在于通过经由一个成员函数访问平均值（也就是说，通过将它封装），你能互换这两个不同的实现（也包括其他你可能想到的），对于客户，最多也就是必须重新编译。（你可以用在后面的 Item 31 中记述的技术来消除这个麻烦。）
将数据成员隐藏在功能性的接口之后能为各种实现提供弹性。例如，它可以在读或者写的时候很简单地通报其他对象，可以检验类的不变量以及函数的前置或后置条件，可以在多线程环境中执行同步任务，等等。从类似 Delphi 和 C# 的语言来到 C++ 的程序员会认同这种类似那些语言中的“属性”的等价物的功能，虽然需要附加一个带圆括号的额外的 set。
关于封装的要点可能比它最初显现出来的更加重要。如果你对你的客户隐藏你的数据成员（也就是说，封装它们），你就能确保类的不变量总能被维持，因为只有成员函数能影响它们。此外，你预留了以后改变你的实现决策的权力。如果你不隐藏这样的决策，你将很快发现，即使你拥有一个类的源代码，你改变任何一个 public 的东西的能力也是非常有限的，因为有太多的客户代码将被破坏。public 意味着没有封装，而且几乎可以说，没有封装意味着不可改变，尤其是被广泛使用的类。但是仍然被广泛使用的类大多数都是需要封装的，因为它们可以从用一种更好的实现替换现有实现的能力中获得最多的益处。
反对 protected 数据成员的理由是类似的。实际上，它是一样的，虽然起先看起来似乎不那么清楚。关于语法一致性和条分缕析的访问控制的论证就像用于 public 一样可以应用于 protected，但是关于封装又如何呢？难道 protected 数据成员不比 public 数据成员更具有封装性吗？实话实说，令人惊讶的答案是它们不。
Item 23 解释了如果某物发生了变化，某物的封装与可能被破坏的代码数量成反比。于是，如果数据成员发生了变化（例如，如果它被从类中移除（可能是为了替换为计算，就像在上面的 averageSoFar 中）），数据成员的封装性与可能被破坏的代码数量成反比。
假设我们有一个 public 数据成员，随后我们消除了它。有多少代码会被破坏呢？所有使用了它的客户代码，其数量通常大得难以置信。从而 public 数据成员就是完全未封装的。但是，假设我们有一个 protected 数据成员，随后我们消除了它。现在有多少代码会被破坏呢？所有使用了它的派生类，典型情况下，代码的数量还是大得难以置信。从而 protected 数据成员就像 public 数据成员一样没有封装，因为在这两种情况下，如果数据成员发生变化，被破坏的客户代码的数量都大得难以置信。这并不符合直觉，但是富有经验的库实现者会告诉你，这是千真万确的。一旦你声明一个数据成员为 public 或 protected，而且客户开始使用它，就很难再改变与这个数据成员有关的任何事情。有太多的代码不得不被重写，重测试，重文档化，或重编译。从封装的观点来看，实际只有两个访问层次：private（提供了封装）与所有例外（没有提供封装）。
Things to Remember
声明数据成员为 private。它为客户提供了访问数据的语法层上的一致，提供条分缕析的访问控制，允许不变量被强制，而且为类的作者提供了实现上的弹性。protected 并不比 public 的封装性强。
