C 箴言：将数据成员声明为private

　　任何反对 public 数据成员的理由同样适用于 protected 数据成员。这就导出了数据成员应该是 private 的结论。

　　首先，我们将看看为什么数据成员不应该声明为 public。然后，我们将看到任何反对 public 数据成员的理由同样适用于 protected 数据成员。这就导出了数据成员应该是 private 的结论，至此，我们就结束了。

　　那么，public 数据成员，为什么不呢？

　　我们从先从语法一致性开始。假如数据成员不是 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 函数。反过来，无论何时被请求都要计算平均值使得 averageSoFar 的运行比较慢，但是每一个 SpeedDataCollection 对象都比较小。

　　谁能说哪一个最好？在内存很紧张的机器（例如，一个嵌入式道旁设备）上，连同在一个很少需要平均值的应用程式中，每次都计算平均值可能是较好的解决方案。在一个频繁需要平均值的应用程式中，速度是基本的需要，而且内存不成问题，保持一个实时变化的平均值更为可取。这里的重点在于通过经由一个成员函数访问平均值（也就是说，通过将他封装），您能互换这两个不同的实现（也包括其他您可能想到的），对于客户，最多也就是必须重新编译。

　　将数据成员隐藏在功能性的接口之后能为各种实现提供弹性。例如，他能够在读或写的时候很简单地通报其他对象，能够检验类的不变量连同函数的前置或后置条件，能够在多线程环境中执行同步任务，等等。从类似 Delphi 和 C# 的语言来到 C 的程式员会认同这种类似那些语言中的“属性”的等价物的功能，虽然需要附加一个带圆括号的额外的 set。

　　关于封装的要点可能比他最初显现出来的更加重要。假如您对您的客户隐藏您的数据成员（也就是说，封装他们），您就能确保类的不变量总能被维持，因为只有成员函数能影响他们。此外，您预留了以后改变您的实现决策的权力。假如您不隐藏这样的决策，您将很快发现，即使您拥有一个类的源代码，您改变任何一个 public 的东西的能力也是很有限的，因为有太多的客户代码将被破坏。public 意味着没有封装，而且几乎能够说，没有封装意味着不可改变，尤其是被广泛使用的类。但是仍然被广泛使用的类大多数都是需要封装的，因为他们能够从用一种更好的实现替换现有实现的能力中获得最多的益处。

　　反对 protected 数据成员的理由是类似的。实际上，他是相同的，虽然起先看起来似乎不那么清楚。关于语法一致性和条分缕析的访问控制的论证就像用于 public 相同能够应用于 protected，但是关于封装又如何呢？难道 protected 数据成员不比 public 数据成员更具备封装性吗？实话实说，令人惊讶的答案是他们不。

　　假如某物发生了变化，某物的封装和可能被破坏的代码数量成反比。于是，假如数据成员发生了变化（例如，假如他被从类中移除（可能是为了替换为计算，就像在上面的 averageSoFar 中）），数据成员的封装性和可能被破坏的代码数量成反比。

　　假设我们有一个 public 数据成员，随后我们消除了他。有多少代码会被破坏呢？任何使用了他的客户代码，其数量通常大得难以置信。从而 public 数据成员就是完全未封装的。但是，假设我们有一个 protected 数据成员，随后我们消除了他。现在有多少代码会被破坏呢？任何使用了他的派生类，典型情况下，代码的数量还是大得难以置信。从而 protected 数据成员就像 public 数据成员相同没有封装，因为在这两种情况下，假如数据成员发生变化，被破坏的客户代码的数量都大得难以置信。这并不符合直觉，但是富有经验的库实现者会告诉您，这是千真万确的。一旦您声明一个数据成员为 public 或 protected，而且客户开始使用他，就很难再改变和这个数据成员有关的任何事情。有太多的代码不得不被重写，重测试，重文档化，或重编译。从封装的观点来看，实际只有两个访问层次：private（提供了封装）和任何例外（没有提供封装）。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有