STRUCT vs. CLASS

关键字struct是C++继承自C语言的一项遗产。作为更加贴切的词汇，class 被引入C++，用来表现类。这个决策造成的结果是：一种语言提供了两个关键字来表示完全一致的概念。在什么情况下应该使用谁，社区内并无定论，甚至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不会带来任何好处，只会带来一堆麻烦。于是，就不难得出这样的结论：我们只应该坚持使用其中一个。

问题是：哪一个?

接口定义时的差别

除了名字不同之外，class和struct唯一的差别是：默认可见性。这体现在定义时和继承时。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，或反过来，所有的前导声明都需要做相应修改。或许编译器并不认为这种不一致是一种错误，但那些不断骚扰你的警告亦会让你不胜其烦。

总结

为什么要以这么大的篇幅讨论struct和class?

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

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

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