# Effective C++读书笔记(22): 数据成员要私有

**守则22: 要把数据成员声明为私有**

> "Declare data members private"

------

***本篇关键词: 封装，访问权限\***

------

开门见山，我们首先来讲为什么数据成员不能是公有的(public)，然后会讲为什么一样的论据也适用于保护(protected)成员。那么为什么我们不能把数据成员声明为公有?

- **语法一致性**，[见第18章](https://zhuanlan.zhihu.com/p/76255433)

试想如果类的公有接口全部都是函数，用户就不用抓耳挠腮地思考到底要不要给一个成员后面加括号，弄清楚现在使用的到底是成员数据还是成员函数，这样一来如果我们把所有成员数据从公有接口拒之门外，类的接口显然会更加用户友好。

```text
myObject.someStuff;  //成员数据
myObject.someStuff();//成员函数
//到底要用哪个?
```

- **访问权限的精确控制**

如果数据成员是公有的，任何代码都可以对其进行读写，根本没有权限控制一说。如果我们希望实现各种读写权限的控制，就只能将其声明为私有，并使用成员函数执行不可读写，只读，可读写，甚至是只写的权限，因为唯一接触非公有成员数据的方法就是通过成员函数 (友元函数当然也可以，只不过在这一章我们先只讨论成员函数，在下一章会讲到友元函数与封装)。

举一个简单的例子用来看这四种权限的实现:

```text
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 readOnly;  //这个成员只读
    int readWrite; //这个成员可读可写
    int writeOnly; //这个成员只写
};
```

- 可能还不够有说服力?来看大宝贝---**封装**(encapsulation)

我们再来举一个例子，假如你在给高速公路上的测速设备写一个应用，有一条需求规定要在每辆车经过的时候，计算出车的当前速度，并把这个速度放进一个数据集里，然后用这个数据集计算平均速度，即averageSpeed函数:

```text
class SpeedDataCollection{
  ...
  public:
    void addValue(int speed);    //把当前测得的速度放进数据集里
    double averageSpeed() const; //利用数据集计算平均速度
  ..
};
```

对于这个函数，我们有两种思路去实现:

1.在类里增加一个表示移动平均(moving  average)的数据成员，然后当averageSpeed函数被调用，只用返回这个数据成员就可以了。但这种方法显然会导致SpeedDataCollection对象所需的内存增大，因为我们引入了新的移动平均成员，以及为了计算移动平均又需要引入当前所有数据的和以及数据的量。

2.在被调用时，现场基于数据集计算这个平均速度。这种方法使用更少内存，只需要定义一个新的inline函数，但在被调用时需要现场计算，使用这个方法肯定要慢于第一种方法。

至于哪个更好，要看具体的环境。在内存较为有限的平台上，例如测速设备的嵌入式系统，而且平均速度不需要太频繁地被计算，例如在车流量较少的路上，第二种方法可能会更好。如果在车流量大的路上，平均速度则需要被频繁并且快速地计算，那么第一种方法可能会更好。

**重点来了**，如果希望把我们的应用做得用户友好，易于扩展和维护，例如可以针对不同的路况使用不同的实现方法，我们只需要把这个平均速度的数据成员封装起来，即将其声明为私有，对用户隐藏起来，需要时通过成员函数接触，不需要时直接使用另一种实现，就可以轻松地根据需求来回切换，最多也就只用重新编译一下。

如果不封装起来，即声明为公有，如果那时要再改需求，恐怕难度就会非常巨大了，因为我们不知道用户在哪以及如何使用了我们的数据成员，稍微改动便有可能导致整个程序的重写。也就是说公有成员即为**未封装**(unencapsulated)的成员，而未封装也就意味着代码的**不可改动**，尤其是对于经常被使用的类。

> "Public means unencapsulated, and practically speaking, unencapsulated means unchangeable."

除此之外，将数据成员对用户隐藏起来(封装起来)还可以给各种各样的实现提供弹性。比如说可以通过成员函数来保证类不变量(class invariant)的限制条件被满足，因为只有成员函数能接触成员数据，对数据所做的改动也都只能遵循成员函数的规定。**可能你会从public接触成员获得一时便利，但这背后牺牲了太多**。

------



同样的论据也适用于**保护**(protected)的数据成员。前面提到的语法一致性和权限控制显然也成立，那么封装呢? 保护的成员是不是比公有成员有更好的封装呢? 答案是**不**。

作者Scott Meyers会在后面提到*某物的封装与因为它的改动而导致可能失效的代码量成反比*。

> "Something's encapsulation is inversely proportional to the amount of code that might be broken if that something changes."

对于数据成员，它们的封装与因为它们的改动而导致可能失效的代码量成反比，例如移除了某个数据成员。

假如我们代码有某些公有的数据成员，在后来的升级中被移除，那么有多少用户代码因此失效了呢: 所有使用了这些数据成员的用户代码。但这是一个不可测的数量，可能趋近于无穷大，也可能趋近于零，因此考虑到最坏的情况，公有数据成员是**完全未封装**的。

假如我们现在有某些保护的数据成员，在后来的升级中也被移除，那么有多少代码也因此失效了呢: 所有使用了它们的子类。但这又是一个不可测的量。因此保护数据成员与公有数据成员是**一样完全未封装**的，因为在两种情况下，改动都有可能造成巨大数量的代码损坏。

结论就是，一旦我们在类中将某些数据成员声明为保护或公有，并且用户已经开始使用这些数据成员，我们将很难对这些数据成员再做出改动，否则可能就会导致巨大数量的代码被重写，重新测试，重新写文档。因此从封装的角度出发，数据成员的访问权限只有两个等级，私有(private)，提供完全的封装，和其它所有的，即protected和public，提供几乎零封装。

**总结:**

- 数据成员一定要声明为私有，这样能给用户提供语法一致性，精确的访问权限控制，保证类不变量的成立，各种功能实现的弹性。
- 保护成员并不比公有成员更具封装性。