大规模C++设计之前言

引言

该书大规模c++软件的开发人员所面临的问题。

在完全正确的c++程序中，也可能导致其运行速度比完成同样功能的c程序慢十倍。

C++技术的不成熟应用不适合大型项目。

介绍在任何c++项目中都应该遵循的重要设计经验。当程序变得很大时，常见的问题是：循环依赖，过度的连接时依赖，过多的编译时依赖，全局名称空间等。

（1）循环依赖

作为一个程序专业人员，第一次看一个软件系统，不能理解或不能单独使用系统中的任何部分就是一种循环依赖设计的征兆。C++对象有一种显著的相互混杂的倾向。循环依赖的特点是没有一个组件可以在没有其他两组的情况单独使用甚至单独测试。草率构建的大型系统会因为循环依赖二过渡变得紧密耦合，从而强烈地抗拒分解。职称这样的系统可能是一场噩梦，通常不可能对其有效的模块测试。

比较起来，层次化物理设计（即没有循环相互依赖）相对容易理解、测试和重用

（2）过度的连接时依赖

如果尝试过链接库中的少量功能程序，就会发现连接时间相对于所希望带来的利益已经不成比例地提高了，于是我们可能会尽量重用“重量级的组件”，而非“轻量级的组件”。

使用对象的好处之一是在需要时很容易地将遗漏的功能加进到对象中。面向对象的这种很具诱惑的特性，使得许多谨慎的开发者将精炼的、审慎考虑过的类变成巨大的“恐龙”，将数量庞大的代码合为一体，而巨大多数客户不会使用其中的大部分代码。每一个客户增加一个新的特性，潜在地增加了实例体积、代码容量、运行时间以及物理依赖，从而增加了其他客户的开销。C++程序常常比必需的大。

（3）过多的编译时依赖

如果尝试过用c++开发一个多文件程序，那么就会知道改变一个头文件可能会潜在地引起多个编译单元需要重新编译。我们迟早会因为重新编译的效果太大而完全拒绝低级类。过度编译时耦合，对于小型项目毫无影响，对于较大项目可能成为支配开发时间的重要因素。

过多地包含（伪）指令，不仅会增加编译客户程序的开销，而且可能增加由于在较低的层次上改变了系统而必须重新客户程序的可能性。

（4）全局名称空间

对于多人合作的c++项目，软件集成常常会出现意想不到的事，特别是增加全局标识符很成问题。

大多数c++的书仅涉及逻辑设计，不涉及物理设计。逻辑设计是指那些属于类、运算符、函数等语言结构的设计。

C++支持完全的逻辑设计。例如，继承是面向对象必不可少的成分，另一个成分是分层（layering），包括用原始的对象来构造类型，并经常嵌入到类的定义中。但是，在许多需要使用分层技术的时候，很多人使用了继承。比如，一个telephone不是一种Receiver、Dial或Cord，而应由这些原始部件组成（或“分层于其上”）。

这种对事物的错误的判断可能导致时间和空间上的低效率，并可能使结构的语义模糊，从而使整个系统更加难维护。有经验的c++程序员知道何时使用或不适用某种特定的语言结构，这是他们成为很有用的人的原因之一。

物理设计涉及的问题包括与系统的实例实体有关的问题（如文件、目录和库等）以及组织问题（如物理实体之间的编译时依赖和连接时依赖等）。好的物理涉及不仅仅是被动地决定系统的现有逻辑实体应如何划分。物理涉及常蕴涵要制备逻辑设计的输出。一个好的物理设计的依赖关系是一种没有循环的图。所以，我们要避免在组件之间暗含循环关系的逻辑设计。

同时满足逻辑设计和物理设计的约束条件，有时是一种挑战。但实际上，有些逻辑设计可能必须重做甚至替换掉，以满足物理设计的质量标准。然而，总是有充分地满足两个领域的接近方案，尽管可能需要费一些时间来发现它们。

对于小项目来说，一个文件系统就能满足要求，因而不必太重视物理设计。但是，对于大型项目来说，一个好的物理设计的重要性就大大提升了。对于非常大的项目来说，物理设计是项目成功的决定性因素。

软件质量可以从很多方面来衡量。可靠性是传统的质量定义。不是所有的软件都能够有效地测试。要想让软件能够有效地测试，必须从一开始就本着这个目标来对它进行设计。

为了易测试而设计，虽然很少成为小项目的最关注的事情，却是成功构造大型和超大型系统最重要的事情。易测试性和质量本身一样，不可能是事后产生的想法：它必须在编写第一行代码之前就预先考虑到。本书套路的设计是如何设计和建立一个大型系统，而不是讨论建设什么样的大系统。

可用性是质量的另一种衡量标准。如果一个软件茶品对于有代表性的预期客户来说，使用起来太复杂、太困难、太笨拙或者令人痛苦，那么，就不会有人使用该软件。

可维护性是衡量支持一个系统工作相对开销的指标。支持工作包括追踪错误、移植到新平台及扩充产品的性能以满足客户期望的未来需求。大型的可维护设计不是碰巧得到的，它们是遵循确保可维护性原则进行项目设计的结果。

           性能是衡量产品的速度和大小的指标。尽管大家都指导面向对象设计在可扩展性和重用性方面有优势，但是，面向对象风范的某些方面，如果使用不当，可能会造成程序的匀性速度更慢，并且占用更多的内存。如果我们一开始没有强调性能目标，我们就可能采纳没有达到性能目标的系统结构或编程方法，除非我们重写整个系统。是否指导哪些地方可以不必太精确以及如何进行性能折衷，是区别软件工程师单纯程序员的标准。

质量的各个方面良好的性能获得有一个共同点：必须在项目的一开始就考虑质量的各个方面。

 

小结：

C++是一个整体而不是C的一个扩充。当项目很大时，采用无组织的、无规程的或幼稚的C++开发方法，最终一定会出现难以维护的问题。

重用不是无开销的，重用蕴含耦合，而耦合不是我们所希望的，没有保障的宠用应该避免。

质量的衡量标准有多个方面：可靠性、功能性、可用性、可维护性以及性能。

获得高质量一项工程的责任：从一开始就积极准确高质量。

良好的开发工具时开发过程的一部分。但是，在大型c++系统中，工具不能弥补固有的设计质量问题。