避免public接口出现数据成员

条款20: 避免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;             // 禁止访问这个int
  int readonly;             // 可以只读这个int
  int readwrite;            // 可以读/写这个int
  int writeonly;            // 可以只写这个int
};
还没说服你？那只得搬出这门重型大炮：功能分离（functional abstraction）。如果用
函数来实现对数据成员的访问，以后就有可能用一段计算来取代这个数据成员，而使用这
个类的用户却一无所知。
例如，假设写一个用自动化仪器检测汽车行驶速度的应用程序。每辆车行驶过来时，计算
出的速度值添加到一个集中了当前所有的汽车速度数据的集合里：
class speeddatacollection {
public:
  void addvalue(int speed);       // 添加新速度值
  double averagesofar() const;    // 返回平均速度
};
现在考虑怎么实现成员函数averagesofar（另见条款m18）。一种方法是用类的一个数据成
员来保存当前收集到的所有速度数据的运行平均值。只要averagesofar被调用，就返回这
个数据成员的值。另一个不同的方法则是在averagesofar每次被调用时才通过检查集合中
的所有的数据值计算出结果。（关于这两个方法的更全面的讨论参见条款m17和m18。）
第一种方法——保持一个运行值——使得每个speeddatacollection对象更大，因为必须为
保存运行值的数据成员分配空间。但averagesofar实现起来很高效：它可以是一个仅用返
回数据成员值的内联函数（见条款33）。相反，每次调用时都要计算平均值的方案则使得
averagesofar运行更慢，但每个speeddatacollection对象会更小。
谁能说哪个方法更好？在内存很紧张的机器里，或在不是频繁需要平均值的应用程序里，
每次计算平均值是个好方案。在频繁需要平均值的应用程序里，速度是最根本的，内存不
是主要问题，保持一个运行值的方法更可取。重要之处在于，用成员函数来访问平均值，
就可以使用任何一种方法，它具有极大价值的灵活性，这是那个在public接口里包含平均
值数据成员的方案所不具有的。
所以，结论是，在public接口里放上数据成员无异于自找麻烦，所以要把数据成员安全地
隐藏在与功能分离的高墙后。如果现在就开始这么做，那我们就可以无需任何代价地换来
一致性和精确的访问控制。

 

转自：

http://old.blog.edu.cn/user2/58817/archives/2006/1095870.shtml