例如，假设写一个用自动化仪器检测汽车行驶速度的应用程序。每辆车行驶过来时，计算出的速度值添加到一个集中了当前所有的汽车速度数据的集合里：

class speeddatacollection {
public:
  void addvalue(int speed);       // 添加新速度值

  double averagesofar() const;    // 返回平均速度
};

现在考虑怎么实现成员函数averagesofar（另见条款m18）。一种方法是用类的一个数据成员来保存当前收集到的所有速度数据的运行平均值。只要averagesofar被调用，就返回这个数据成员的值。另一个不同的方法则是在averagesofar每次被调用时才通过检查集合中的所有的数据值计算出结果。（关于这两个方法的更全面的讨论参见条款m17和m18。）

第一种方法——保持一个运行值——使得每个speeddatacollection对象更大，因为必须为保存运行值的数据成员分配空间。但averagesofar实现起来很高效：它可以是一个仅用返回数据成员值的内联函数（见条款33）。相反，每次调用时都要计算平均值的方案则使得averagesofar运行更慢，但每个speeddatacollection对象会更小。

谁能说哪个方法更好？在内存很紧张的机器里，或在不是频繁需要平均值的应用程序里，每次计算平均值是个好方案。在频繁需要平均值的应用程序里，速度是最根本的，内存不是主要问题，保持一个运行值的方法更可取。重要之处在于，用成员函数来访问平均值，就可以使用任何一种方法，它具有极大价值的灵活性，这是那个在public接口里包含平均值数据成员的方案所不具有的。

所以，结论是，在public接口里放上数据成员无异于自找麻烦，所以要把数据成员安全地隐藏在与功能分离的高墙后。如果现在就开始这么做，那我们就可以无需任何代价地换来一致性和精确的访问控制。