struct vs. class

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

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

很多C++开发者可能并不同意这一点。从他们的逻辑和经验出发，struct仍然应该用来定义那些只有数据，没有行为的“类”—— 它们事实上是C语言中的结构体；而class只应该用来定义真正的“类”——那些有行为的家伙。

作为一门多范式的语言，C++可以支持面向过程风格和面向对象风格的编程。C++程序员也有足够的底气来宣称自己在使用混合风格。

我偶尔也会使用混合风格。但对于一致性的追求会让我以一种风格为主，那就是面向对象。只有在极个别场合，我才会基于成本的考虑和务实的选择而采用过程风格，它占的比例可能连1％也不到，并且都是在定义自由函数。

而在面向对象设计中，有数据无行为的类通常是设计问题的征兆。尽管这样的类在社区，尤其是C++社区内非常普遍，但这也正是许多项目都在“焦油坑”中挣扎的原因。我已经很久没有机会定义这样的类了。所以，struct不会基于这样的原因而被我使用。

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

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

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

class Invokable{public:   virtual Any& invoke() = 0;   virtual ~Invokable() {}};

struct Invokable{   virtual Any& invoke() = 0;   virtual ~Invokable() {}};

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

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

对于实体类，往往存在私有数据（没有数据，只有实现的实体类也往往意味着坏味道 ），而class的默认私有性，让这种场景变成了它的show time。

class Foo{   int    a;   double b; public:   Foo(int);   void doSomething();};

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

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

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

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

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

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

所以，struct的默认公开性在定义实体类的时候也更有价值。虽然这个价值相对于用它定义接口类从比例上小一些（但绝对价值是一样的）。

啰嗦了半天，我真正的目的不在于讨论到底应该用struct还是class来定义一个类，而是想明确，究竟是接口更重要，还是实现细节更重要。在明确了这一点之后，我们才会清楚，该如何应对头文件里类定义所带来的物理耦合问题，但那是后续的故事。

另外需要强调的是，无论你使用class还是struct，都应该只选择其中一个，而不是混合使用（我过去的做法就是，定义接口类时使用struct，定义实体类时用class）。否则，在大量使用前导声明的情况下，一旦某个使用struct的类改为class，所有的前导声明都需要做相应修改。或许编译器并不认为这种不一致是一种错误，但那些不断骚扰你的警告亦会让你不胜其烦。