大部分关于C++的书中只讲述了逻辑设计。逻辑设计是指从属于诸如类、运算符、函数等语言结构的那些设计。例如，一个特定的类是否应该有一个拷贝构造函数，就是一个逻辑设计问题。决定一个特定的运算符（如操作符= =）应该是一个类成员函数还是一个自由函数（即非成员函数），也是一个逻辑问题。甚至，选择一个类的内部数据成员的类型也属于逻辑设计问题。

C++支持绝大多数丰富的逻辑设计方案。例如，继承是面向对象范型的一个基本要素。还有一个要素称为分层，涉及由更基本的对象组合而成的类型，通常直接嵌入在类的定义中。不幸的是，很多程序员可能在需要分层的地方使用了继承。例如，一个Telephone不是一种Receiver、Dial或Cord，而是由它们的基本部件组合而成（或“分层而来”）。

以这种方法错误地判断某种情形，可能会导致时间和空间上的低效率，也会让语义结构变得难以理解，整个系统变得难以维护。因为知道何时使用，何时不使用聚合关系这种特定的语言结构，经验丰富的C++开发人员十分重要。

逻辑设计问题不涉及“在什么地方放置一个类定义”这样的问题。从纯逻辑的角度看，文件作用域中的所有定义都存在于单一空间的同一层次上，这些定义之间没有界限。相对于类成员的定义来说，一个类在何处定义和是否支持自由运算符的问题与逻辑设计无关。重要的是这些逻辑实体如何组织在一起，形成一个能工作的程序；而且，由于将整个程序看作一个单元，所以没有单独的物理依赖的概念。程序作为一个整体依赖于自己。

关于逻辑设计的好书有很多（见参考书目）。不幸的是，也有许多问题只有在程序变得很大时才会出现，这些书中没有讲到。这是因为，与成功的大型系统设计有关的很多内容应归入到一个特殊类别，本书把它们称为物理设计。

物理设计解决的是与一个系统物理实体（像文件、目录和库等）密切联系的问题和物理实体之间的编译时依赖或者链接时依赖之类的组织问题。例如，让类Telephone的一个成员ring()成为一个inline函数，为了完成编译，这将迫使Telephone的所有客户端不仅要查看ring()的声明，也要查看ring()的定义。无论是否将ring()声明为inline函数，ring()的逻辑行为都一样，受影响的是Telephone与其客户端之间物理耦合的程度和特性，使用Telephone维护所有程序的成本也因此受到影响。

然而，优秀的物理设计不只是包含消极地决定如何分割一个系统现有的逻辑实体。物理设计的含义通常会决定逻辑设计决策的结果。例如，逻辑域中类之间的关系，如IsA、HasA和Uses，转换成物理设计领域中组件之间的一个DependsOn关系。此外，一个合理的物理设计依赖关系会构成一个无循环的图。因此，我们避免选择组件之间隐含循环物理依赖关系的逻辑设计。

有时同时满足逻辑设计和物理设计的约束条件具有挑战性。实际上，为满足物理设计质量标准，某些逻辑设计可能必须改写甚至替换。然而，依据我的经验，总是有足够满足两个领域的解决方案，尽管开始时要费一些时间去寻找。

小型项目可以很容易地放入单个目录，可能很少关注物理设计。然而，对于大型项目，合理的物理设计重要性陡增。对于庞大的项目，物理设计将是决定项目成功的关键因素。