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