STRUCT vs. CLASS

C++ · godsme · 于 发布 · 1083 次阅读
816

关键字structC++继承自C语言的一项遗产。作为更加贴切的词汇,classC++引入,用来表现。这个决策造成的结果是:一种语言提供了两个关键字来表示完全一致的概念。在什么情况下应该使用谁,社区内并无定论,甚至C++的发明者Bjarne Stroustrup也无法给出毫不含糊的建议。

一种流行的看法

如果只是名字的差别,那么毫无疑问,在任何时候都应该使用class,毕竟它更直观、准确。

很多C++开发者可能并不同意这一点。从他们的逻辑和经验出发,struct 仍然应该用来定义那些只有数据,没有行为的“类”—— 它们事实上是C语言中的结构体;而class只应该用来定义真正的类——那些有行为的家伙。甚至有团队规定, 一旦你使用struct来定义一个类型,则其就不应该有任何行为;否则,就需要使用class

如果使用C++开发一套库,却要提供一套可供C语言调用的接口,这样的规定是合理的。毕竟,C语言是不认识超出自己理解范围的任何C++语法的。

如果不是基于此类目的,这种规定就是自找麻烦。一个类型是不是应该有行为,是动态的。尽管最初你定义它的时候,它是以持有数据为主要目的。但你无法确保随后你不会因为某种目的需要为其添加一个方法。

比如,最初的时候你定义了这样一个数据结构,由于它是进程间通信的消息包,所以在你看来,它应该是一个纯粹的数据类——结构体。于是你将其定义为:

struct PDU 
{
  time_t timestamp; 
  data_t today;
  int value;
};

随后你发现,在使用的过程中,总是需要重复这样的代码:

PDU pdu;

pdu.timestamp = now();
pdu.today     = today();
pdu.value     = value;

其中,前两个字段的设置方式是确定的,都是取系统的当前时间和日期。作为一个专业程序员,这种重复让你无法忍受,所以你决定实现一个类似于C语言的初始化函数:

void init_pdu(PDU& pdu, int value) {
        pdu.timestamp = now();
        pdu.today     = today();
        pdu.value     = value;
}

然后,你就可以这样来调用:

PDU pdu;

init_pdu(pdu, 5);

这是一种典型的C语言处理手法。如果你是个更老练的C++程序员,会选择使用构造函数:

struct PDU 
{
  explicit PDU(int value) 
    : timespace(::now())
    , today(::today())
    , value(value)
  {}

  time_t timestamp; data_t today;
  int value;
};

这种做法没有带来任何副作用:没有任何额外的内存和性能开销。甚至,严格来讲,由于使用了初始化列表,它的性能还略微提高了。

除此之外,你还收获了一些其它好处:
* 它的代码和数据被毫无争议,无法分割的放在了一起,有着更好的内聚性可理解性;
* 具备某种强制性:你永远也不可能忘记调用构造函数;
* 客户代码更加的简洁,直观。比如:

PDU pdu(5);

基于这些理由,我们让类型PDU有了一个行为。按照之前的规定,我们需要把它从struct改成class。这似乎不难做到,但问题在于:为什么我们需要关注这件事情?如果从一开始它就是一个class,哪怕它没有任何行为,我们宝贵的时间和精力就不会被无谓的消耗。

这还不算完。当你将一个类型由struct改为class后,所有对其进行声明的地方都需要做同步的修改。否则,编译器将会发出警告。作为一个纪律严明的专业软件公司的雇员,你被要求消除掉所有告警。于是,更多的毫无价值的精力被浪费了。

所以,以这种原则来区分struct还是class不会带来任何好处,而是一堆麻烦。于是,就不难得出这样的结论:我们只应该坚持使用其中一个。

问题是:哪一个?

接口定义时的差别

除了名字不同之外,classstruct唯一的差别是:默认可见性。这体现在定义时和继承时。struct在定义一个成员,或者继承时,如果不指明,则默认为public; 而class则默认为 private

但这不是我要讨论的重点,介绍语言的基础特性并不是本文的目标,重点是这样的差别会产生出不同的代码。

比如,现在要定义一个纯虚类,用两个不同的关键字,会导致如下不同的结果:

class Interface 
{
public:
  virtual int invoke() = 0;
  virtual ~Interface() {} 
};

struct Interface 
{
  virtual int invoke() = 0;
  virtual ~Interface() {} 
};

两者差别很小,你或许并不在意。但对我而言,一个纯虚类,从逻辑上本来就是一个只有公开方法声明、没有实现细节的接口类。它所声明的一切都应该是公开的。在这样的契约关系下,如果再通过public指明其公开性,这属于画蛇添足。

懒惰的我讨厌冗余,讨厌重复。更何况从平衡和美感的角度看,那个横立的public就像洁白墙面上的一沫蚊子血,显得格外刺眼。

继承时的差别

而这并非故事的全部。struct的默认公开性还体现在继承时:像成员一样,如果未指明,struct对于父类的继承默认为public继承。而class则恰恰相反。这个规则本身没有问题,问题在于我们如何选择。

作为一个有经验的C++程序员,在至少百分之九十以上的情况下,都会使用公有继承(对于很多C++程序员,这个比例是百分之百)。这就意味着,在绝大多数情况下(如果不是全部的话),我们都要一遍遍的书写public——这不是一个理性的选择。(Typing does take time, doesn't it?)

class Derived 
  : public Base1
  , public Base2
  , public Base3 
{ // more code
};

而一旦我们换作使用struct来定义一个类,则所有不必要的 public声明就自然省略。如下:

struct Derived 
  : Base1
  , Base2
  , Base3 
{ // more code
};

确实干净多了,不是吗?

实体类定义时的差别

实体类不同于接口类,往往存在私有数据(没有数据,只有实现的实体类也往往意味着坏味道,一些表现算法的策略类除外),而class默认私有性,让这种场景变成了它的舞台。

class Foo 
{ 
  int a; 
  double b;

public: 
  Foo(int);
  void doSomething(); 
};

这个类把私有数据定义在前面,把公开方法定义在后面,所以可以利用 class的默认私有性。

但这样的定义布局并不只是顺序上的差异。我们的认知习惯和阅读顺序决定了我们总是希望把更重要的、更希望人们了解的信息摆在一目了然的位置。而不是让别人穿越重重迷雾才能找到自己的关注点。我们希望别人更容易理解我们的意图, 而不是试图挑战别人的智商和耐心。

所以,信息摆放的顺序就成了一件有所谓的事情。你如果认为私有实现细节是更重要的,那就把私有数据摆在前面。否则,就把公开方法置于前列。

对于把程序理解为“数据结构+算法”的程序员,尽管正在使用面向对象的元素——“类”,却依然会认为理解一个程序的前提是理解它的数据结构。在这样的价值驱动下,把私有数据摆在前面就是完全合情合理的。数年前,我就曾在一本C++相关的书中读到过这样的建议。

但对于越来越确信信息隐藏对软件之重要的我,则更倾向于认为公开接口才是理解一个模块最关键的知识。当试图去使用一个模块时,我总是会优先查看它的测试用例(如果有的话),然后再去看它的公开接口声明。一般而言,这对于理解它能做什么,以及如何使用它已经足够;接口声明处的私有元素反而会干扰我对一个模块的理解。只有在好奇心的驱使下,我才会进一步去看看它的实现。

基于这样的认知,当定义一个类的时候,我会把公开方法定义在前面。至于私有的内容,我总是会竭尽所能的不希望引起人们的注意,宁愿付出一些代价,也要把它们藏到别人在类声明里看不到的地方,更不会放在前面扰乱视听。

所以,我仍然会选择struct来定义实体类。如下:

struct Foo 
{
  Foo(int);
  void doSomething();

private:
  int a;
  double b; 
};

保持一致

无论是接口,还是实现类;无论是一个类以行为为中心,还是以数据为中心,使用 struct 而不是 class 都会给你的编程带来一定的便利。

基于某些原因——无论是遗留系统的阻力,还是个人偏好的牵引——在了解了这所有的一切之后,你可能仍然选择使用class。这没有太大的问题,毕竟你的程序你做主。

但需要强调的是,无论你喜欢class还是struct,都应该坚持选择其中一个,而不是混合使用(比如不要在定义数据类的时候使用 struct,定义行为类的时候使用class)。否则,在大量使用前导声明的情况下,一旦某个使用struct的类改为class,或反过来,所有的前导声明都需要做相应修改。或许编译器并不认为这种不一致是一种错误,但那些不断骚扰你的警告亦会让你不胜其烦。

总结

为什么要以这么大的篇幅讨论structclass?

首先,因为我所写的所有C++相关文章都会使用struct来定义(在实际项目中也一直如此)。如果不在这里给出说明,一些人可能会感到困惑。

其次是因为此问题在社区内尚无定论,很多团队在给出structclass的选择问题时,给出的选择理由并不成立。一次深入的讨论对于社区是有价值的。

最后,通过这样的讨论,我希望阐述的并非结论,而是其背后所遵守价值观和原则。这会有助于理解我其它文章的内容。无论话题如何变化,我都会遵守一致的价值观和原则。


「软件匠艺社区」旨在传播匠艺精神,通过分享好的「工作方式」和「习惯」以帮助程序员更加快乐高效地编程。
本帖已被设为精华帖!
暂无回复。
需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。