第一章：致读者
n对于程序设计和设计技术的理解远比对细节的理解更重要，而这种理解的根本是时间和实践。
n要想从C++中获益，他们就必须花时间去学习，以使适合于C++的程序设计风格和技术真正变成自己的东西。
n一个良好的用户定义类型与一个内部类型之间的差异仅仅在于器定义的方式，而不在使用方式。
n在理想情况下，你需要通过三个步骤完成设计一个程序的工作。首先，你取得对问题的一个清晰的理解（分析）；然后你标识出在一个解决方案中所涉及的关键性概念（设计）；最后，你用一个程序表达这个解决方案（编程）。常常只有通过在一个程序中描述他们，以及让程序以可接受的方式运行的努力之下，才能真正被清楚地理解。这正是程序设计语言选择的关键之处。
n写出好的程序，最关键的就是去设计类，识它们中的每一个都能很清楚地表示某个概念。这经常意味着你必须集中注意一些这样的问题：这个类的对象应该如何建立？这个类对象能够被复制、销毁吗？什么操作能作用于这个对象？如果这样的问题不存在很好的回答，对应的概念或许识从一开始就很不清楚。这时该多想想有关的问题以及为它所设定的解决方案，而不是立即开始去围绕着那个问题编码。
n概念不会存在于真空之中；总是存在着相互关联的一簇簇的概念。将程序里各个类按它们之间的关系组织起来——即确定一个解决方案所涉及到的不同概念之间的准确关系——常常比单独地列出一些类更困难。考虑两个类，A和B。像“A调用B的函数”，“A建立起一些B”，“A包含一个B成员”之类的关系很少会造成重要的问题。
n威力最大的一种管理复杂性的智力工具就是某种层次性的序关系，也就是说，将相互有关的概念组织到一个树性的结构中，使最一般的概念成为树根。在C++里，派生类表示的就是这种结构。一个程序常常能组织为一组类，或者一组类的有向无环图。这是，程序远刻画一组基类，每个都有它的一组派生类。虚函数常常能被用于为一个概念的最一般版本（一个基类）定义操作。如果必要，可以针对特定的类（派生类），对这些操作的解释做进一步的精确化。 有时，甚至一个有向无环图看起来也不足以组织起一个程序里的概念；有些概念似乎具有内在的相互依赖性。在这种情况下，我们应该设法将这种循环依赖关系局部化，使他们不会影像程序的整体结构。如果你无法清楚这种相互依赖，也无法将其局部化，那么你很可能进入了一个困境，没有一种程序设计语言能够帮你跳出来。除非你能设计出在基本概念之间的某种很容易陈述的关系，否则那个程序多半会变得无法管理。 解开依赖图的一种最好的工具就是界面和实现的清晰分离。抽象类使C++处理这种问题的基本工具
n忠告：
n在编写程序使，你是在为你针对某个问题的解决方案中的思想建立起一种具体表示。让程序的结构尽可能地直接反映这些思想。
n如果你能吧“它”看成一个独立的概念，就把它做成一个类。
n如果你能吧“它”看成一个独立的实体，就把它做成某个类的一个对象。
n如果两个类有共同的界面，将此界面做成一个抽象类。
n如果两个类的实现有某些显著的共同东西，将这些共性做成一个基类。
n如果一个类是一种对象的容器，将他做成一个模板。
n如果一个函数实现对某容器的一个算法，将它实现为对一族容器可用的模板函数。
n如果一组类、模板等互相之间有逻辑关系，将他们放进一个命名空间里。
n在你定义的一个并不是实现某个像矩阵或复数这样的数学对象类时，或者定义一个低层的类型如链表时：
n不要使用全局数据（使用成员）。
n不要使用全局函数
n不要使用公用数据成员
n不要使用友元，除非为了避免第一三点。
n不要在一个类里面放那种为了说明一个类所存储数据的情况而放置的标志域。
n不要使用内联函数，除非作为效果显著的优化。
