读书笔记 effective c Item 22 将数据成员声明成pr

作者:计算机教程

访问控制

为数据成员提供getter和setter可以实现对数据更加精细的访问控制,比如实现一个只读的属性:

class readOnly{
  int data;
public:
  int get() const { return data; }
}

事实上,在C#中提供了访问器(又称属性)的概念, 每个数据成员都可以定义一套访问器(包括setter和getter),使用访问器不需要使用括号:

public class readWrite{
  private string _Name;
  public string Name{
    set { this._Name = value; }
    get { return this._Name; }
  }
}
ReadWrite rw;
// 将会调用set方法
rw.Name = alice;

2. 为什么数据成员不能是protected的?

上面的论证对于protected数据成员来说是类似的。事实上,它们是完全相同的,虽然一开始看上去不是这样。在论证数据成员不能为public时,句法一致性和细粒度访问控制这两个原因同样适用于protected成员,但是封装呢?protected数据成员不是有比public数据成员更好的封装性么?令人感到吃惊的回答是,它们不是。

Item 23解释了封装性同一些东西发生变化引起的代码可能被破坏的数量成反比。一个数据成员的封装型,同数据成员发生变化引起的代码可能被破坏的数量成反比,举个例子,如果数据成员从类中移除。(可能被一个计算代替,正如在averageSoFar中实现的)。

假设我们有一个public数据成员,我们将其删除。有多少代码会被破坏?所有使用它的客户代码将被破坏,一般情况下这应该是个未知的数量。Public数据成员因此完全没有被封装。但是假设我们有一个protected数据成员,我们将其删除。现在会有多少代码被破坏呢?所有使用它的派生类,同样的,这也是未知数量的代码。Protected数据成员同public数据成员一样也没有被封装,因为在两种情况中,如果数据成员被修改,都有未知数量的客户代码会被破坏。这是违反直观的,但是一个经验丰富的库实现人员会告诉你,这就是真的。一旦你将一个数据成员声明成public或者protected并且客户开始使用它,很难改变数据成员的任何东西。因为一旦修改了,太多的代码会被重新实现,重新测试,重新编辑文档,重新编译。从封装的角度来说,真的只有两种访问级别:private(提供了封装)和其它的(没有提供封装)。

可维护性

封装所有的数据可以方便以后类的维护,比如你可以随意更改内部实现,而不会影响到既有的客户。例如一个SpeedDataCollection需要给出一个平均值:

class SpeedDataCollection{
public:
  void add(int speed);
  double average() const;
};

average()可以有两种实现方式:维护一个当前平均值的属性,每当add时调整该属性;每次调用average()时重新计算。两种实现方式之间的选择事实上是CPU和内存的权衡,如果在一个内存很有限的系统中可能你需要选择后者,但如果你需要频繁地调用average()而且一点内存不是问题,那么就可以选择前者。

你的实现方式的变化不会影响到你的客户。但如果avarage()不是方法而是一个共有数据成员。 那么对于你的每次实现方式变化,客户就必须重新实现、重新编译、重新调试和测试它们的代码了。

2.1 一致性

让我们从句法的一致性开始(Item 18)。如果数据成员不是Public的,那么客户访问对象的唯一方法就是通过成员函数。如果所有的公共接口都是函数,客户就不必记住访问一个类的成员时是否使用括号了。这方便了客户的使用。

Item 22:数据成员应声明为私有 Effective C 笔记

Item 22: Declare data members private

数据成员声明为私有可以提供一致的接口语法,提供细粒度的访问控制,易于维护类的不变式,同时可以让作者的实现更加灵活。而且我们会看到,protected并不比public更加利于封装。

2.2 对数据成员访问的精确控制

如果一致性没有让你信服,那么使用函数可以使你对数据成员的访问有更加精确的控制呢?如果你将数据成员声明成public的,每个人对其都有读写权限,但是如果你使用函数来对值进行获取(get)或者设置(set),你就可以实现不可访问(no access),只读访问(read only)和读写(read-write)访问。如果你需要,你甚至可以实现只写(write-only)访问:

 1 class AccessLevels {
 2 
 3 public:
 4 
 5 ...
 6 
 7 int getReadOnly() const { return readOnly; }
 8 
 9 void setReadWrite(int value) { readWrite = value; }
10 
11 int getReadWrite() const { return readWrite; }
12 
13 void setWriteOnly(int value) { writeOnly = value; }
14 
15 private:
16 
17 int noAccess; // no access to this int
18 
19 int readOnly; // read-only access to this int
20 
21 int readWrite; // read-write access to this int
22 
23 int writeOnly; // write-only access to this int
24 
25 };

 

这种细粒度的访问控制是很重要的,因为许多数据成员应该被隐藏起来。很少情况下需要所有的数据成员都有一个getter和一个setter。

来看看 protected

既然共有数据成员会破坏封装,它的改动会影响客户代码。那么protected呢?

面向对象的精髓在于封装,可以粗略地认为一个数据成员的封装性反比于它的改动会破坏的代码数量。比如上述的average如果是一个public成员,它的改动会影响到所有曾使用它的客户代码,它们的数量是大到不可知的(unknowably large amount)。如果是protected成员,客户虽然不能直接使用它,但可以定义大量的类来继承自它,所以它的改动最终影响的代码数量也是 unknowably large。

protectedpublic的封装性是一样的!如果你曾写了共有或保护的数据成员,你都不能随意地改动它们而不影响客户代码!

http://www.bkjia.com/cjjc/1052685.htmlwww.bkjia.comtruehttp://www.bkjia.com/cjjc/1052685.htmlTechArticleItem 22:数据成员应声明为私有 Effective C 笔记 Item 22: Declare data members private 数据成员声明为私有可以提供一致的接口语法,提供细粒度的访...

2.3 封装

仍然没有说服力?该是使出杀手锏的时候了:封装。如果你通过一个函数来实现对一个数据成员的访问,日后你可能会用计算来替代数据成员,使用你的类的任何客户不会觉察出类的变化。

举个例子,假设你在实现一个应用,自动化设备使用这个应用来记录通过车辆的速度。当每辆车通过的时候,速度被计算出来,然后将结果保存在一个数据集中,这个数据集记录了迄今为止收集的所有速度数据:

 1 class SpeedDataCollection {
 2 
 3 ...
 4 
 5 public:
 6 
 7 void addValue(int speed); // add a new data value
 8 
 9 double averageSoFar() const; // return average speed
10 
11 ...
12 
13 };

 

现在考虑成员函数averageSoFar的实现。一种实现的方法是在类中定义一个数据成员,用来表示迄今为止所有速度数据的平均值。当averageSoFar被调用的时候,它只是返回这个数据成员的值。另外一种方法是在每次调用averageSoFar的时候重新计算平均值,这可以通过检查数据集中的每个数据值来做到。

第一种方法使得每个SpeedDataCollection对象变大,因为你必须为保存平均速度,累积总量以及数据点数量的数据成员分配空间。然而,averageSoFar可以被很高效的实现出来;它只是一个返回平均速度的内联函数(见Item 30)。相反,在请求的时候才计算平均值会使得averageSoFar运行非常缓慢,但是每个SpeedDataCollection对象会比较小。

谁能确定哪个才是更好的呢?在一台内存吃紧的机器上,并且应用中对平均值的需要不是很频繁,每次计算平均值可能会是一个更好的选择。在一个对平均值需求频繁的应用中,速度很重要,但内存充足,你可能更喜欢将平均速度保存为数据成员。这里的重要一点是通过一个成员函数来访问平均值(也就是将其封装起来),你可以在这些不同实现之间来回切换,客户端至多只需要重新编译就可以了。(通过Item31中描述的技术,你甚至可以不用重新编译)

将数据成员隐藏在函数接口后边可以灵活的提供不同种类的实现。举个例子,它可以使下面这些实现变得很简单:当数据成员被读或者写的时候通知其它对象;验证类的不变性和函数的先置和后置条件;在多线程环境中执行同步等等。从其它语言(像Delphi和C#)转到C 的程序员将会识别出来C 的这种功能同其它语言中的“属性”是等同的,但是需要额外加一对括号。

封装比它起初看起来要重要。如果你对客户隐藏你的数据成员(也就是封装它们),你就能够确保类能一直维持不变性,因为只有成员函数能够影响它们。进一步来说,你保留了日后对实现决策进行变动的权利。如果你没有将这些决策隐藏起来,你将会很快发现即使你拥有一个类的源码,但是你修改public成员的能力是及其受限的,因为如果修改public成员,太多的客户代码会被破坏。Public意味这没有封装,更实际的讲,未封装意味这不能变化,特别对被广泛使用的类更是如此。因此对广泛使用的类最需要进行封装,因为它们最能受益于将一个实现替换为一个更好的实现。

本文由nba买球发布,转载请注明来源

关键词: