大规模C++程序设计

声明与定义

定义：一个声明将一个名称引入一个程序；一个定义提供了一个实体（例如，类型、实例、函数）在一个程序中的惟一描述。

一个声明就是一个定义，除非： 它声明了一个没有详细说明函数体的函数； 它包含一个 extern 定义符并且没有初始化函数或函数体； 它是一个包含在一个类定义之内的静态类数据成员的声明； 它是一个类名声明； 它是一个 typedef 声明

一个定义就是一个声明，除非： 它定义了一个静态类数据成员； 它定义了一个非内联成员函数。

不必要的编译时依赖

一个大型的C++程序通常会比同样的C程序有更多的头文件。一个文件包含不必要的头文件，是造成C++中过多耦合的原因。不管这些不必要的头文件是否会用到，过多的包含伪指令（#include），不仅会增加编译时的开销，而且也可能增加由于较低层次上改变了系统而必须重新编译整个程序的可能性。

如果忽略编译时依赖，那么有可能使得系统中每一个编译单元几乎包含每一个头文件，最终使整个工程项目编译变得跟爬行一样慢，这样会随着项目规模暴增。

不必要的全局空间污染

尽量别把typdef这样的类型定义放到类外，尽量放到类内，否则维护者不好找其定义。这样一来，声明新类型就可以：className::NewType object了。 遵循以上规则，就可以使冲突降到最低，同时使得在大系统中寻找逻辑实体更加容易。

物理设计

好的物理设计不仅仅是被动地决定系统的现有逻辑实体应如何划分。物理设计常蕴含要支配逻辑设计的输出。一个好的物理设计是一个没有循环的图。小项目物理设计不太重要，但是大型项目，物理设计往往是成功的关键。

作者描述了一个对开发者（类的开发者）和客户（类的客户，即使用类的其他开发者）都有用的组织（类成员布局）。此布局细分为三组：创建函数（CREATOR)、操纵函数（MANIPULATOR）和 访问函数（ACCESSOR），其中前两者是非常量成员函数，后者是常量成员函数。作者说明对于像 包装器（wapper） 这样的非常大型的类来说，其他组织方式可能更实用。大致布局如下代码所示

class Car {
// ...
public:
	// CREATORS
	Car(int cost = 0);
	Car(const Car &car);
	~Car();
	
	// MANIPULATORS
	Car& operator=(const Car &car);
	void addFuel(double numberOfGallons);
	void drive(double deltaGasPedal);
	void turn(double angleInDegrees);
	// ...
	
	// ACCESSORS
	double getFuel() const;
	double getRPMs() const;
	double getSpeed() const;
	// ...
};

有些人会设法把成员函数分组为 get/set 对，如图 1-6 所示。对某些用户来说，这种风格是概念误导的结果，认为一个对象不过就是一个有数据成员的公共数据结构，每一个数据成员必须既有一个“get”函数（访问函数）又有一个“set”函数（操纵函数）。这种风格本身可能（有时候）会阻碍真正封装接口的产生，在真正封装的接口中，数据成员没有必要透明地反映在对象的行为中。

图 1-6 所示的代码：

class Car {
	double d_fuel;
	double d_speed;
	double d_rpms;
	
public:
	Car(int cost = 0);
	Car(const Car &car);
	~Car();
	
	double getFuel() const;
	void setFuel(double numbersOfGallons);
	
	double getRPMs() const;
	vodi setRPMs(double rpms);
	
	double getSpeed() const;
	void setSpeed(double speedInMPH)
};

个人觉得这段话最后一句翻译有问题，不过看这段话应该也能够明白作者的意思。类的数据成员是类的实现，类需要的是合理的接口，而并非生搬“每个数据成员需要成对的访问器函数”，这样有时候会阻碍开发者找到真正合适的接口。比如 图 1-6 代码的类接口明显不如开始所示的类接口（汽车 一般是耗油和加油，而不可能直接设置油箱里的剩余油量 ╮（﹀＿﹀）╭ ）。

最后，还有在哪里放置数据成员的问题。完全封装好的类没有公共数据。从逻辑角度来看，数据成员只是类的实现细节。因此，许多人都愿意把类的实现细节（包括数据成员）放在类定义的末尾，如图 1-7所示。

图 1-7代码如下所示：

class Car {	
public:
	Car(int cost = 0);
	Car(const Car &car);
	
	// ...
private:
	double d_fuel;
	double d_speed;
	double d_rpms;
};

虽然这个组织对于不成熟的客户来说可能更具可读性，把实现细节藏在类定义末尾的尝试掩饰了它们并未被隐藏的事实。在头文件中实现细节的存在会影响编译时耦合的程度，这种耦合不会因为在类定义中重新放置这些细节就简单地消失。 因为本书要研究物理的和组织的设计问题，我们始终把头文件中的实现细节放在公共接口的前面（部分原因是要强调它们的存在）。在第 6 章中，我们会讨论像这样的实现级的混乱如何才能被整个地从一个头文件中移走，从而确实对客户隐藏。

所以，慢慢看到第 6 章吧，看作者的方法是什么。不过，个人觉得极有可能就是使用 pimpl 模式 （或 pimpl机制）来在接口（头文件中）隐藏真正的实现（简单来说是在接口类中包含一个真正实现类的对象的私有指针，所有的实现最终都是由这个对象去完成，而接口类本身来说，就相当于一个纯接口层）。╮（￣▽￣）╭ 关于 pimpl 模式的一篇文章链接：PIMPL 模式的实现及应用

每次你增加一个特征去取悦一个人，你就扰乱和潜在地骚扰了你的客户库的其他人。曾经发生过这样的事情：原本是轻量级和很有用的类，经过一段时间后变得过于臃肿，不但不能做好每件事情，而且毫不夸张地说，它们已经变得每件事情都做不好了。

说的多好 = =贪心必须死