1. 不要用C + +主动重写我们已有的C代码,除非我们需要对它的功能做较大的调整,(也就
是说,不破不立)。
2. 要区别类的创建者和类的使用者(客户程序员)。
3. 当我们创建一个类时,要尽可能用有意义的名字来命名类。
4. 数据隐藏允许我们(类的创建者)将来在不破坏用户代码(代码使用了该类)的情况下
随心所欲地修改代码。为实现这一点,应把对象的成员尽可能定义为private, 而只让接口部分
为p u b l i c,而且总是使用函数而不是数据。
5. 不要陷入分析瘫痪之中。有些东西只有在编程时才能学到并使各种系统正常。
6. 我们的分析和设计至少要在系统中创建类、它们的公共接口、它们与其他类的关系、特
殊的基类。
7. 记住软件工程的基本原则:所有的问题都可以通过引进一个额外的间接层来简化
(Andrew Koenig向我解释了这一点)。这是抽象方法的基础,而抽象是面向对象编程的首要
特征。
8. 使类尽可能地原子化。也就是每个类有一个单一、清楚的目的。
9. 从设计的角度,寻找并区分那些变化和不变的成分。
10. 注意不同点。两个语义上不同的对象可能有同样的操作或反应,自然就会试着把一个
作为另一个的子类以便利用继承性的好处。这就叫差异,但并没有充分的理由来强制这种并不
存在的父子关系。一个好的解决办法是产生一个共同的父类:它包含两个子类
11. 注意在继承过程中的限制。最清晰的设计是向被继承者加入新的功能,而如果在继承
过程删除了原有功能,而不是加入新功能,那这个设计就值得怀疑了。
12. 不要用子类去扩展基类的功能。如果一个类接口部分很关键的话,应当把它放在基类
中,而不是在继承时加入。如果我们正在用继承来添加成员函数,我们可能应该重新考虑我们
的设计。
13. 一个类一开始时接口部分应尽可能小而精。在类使用过程中,我们会发现需要扩展类
的接口。然而一个类一旦投入使用,我们要想减少接口部分,就会影响那些使用了该类的代码
14. 大声朗读我们的类,确保它们是合理的。读基类时用“is-a”,读成员对象时用“has-a”。
15. 在决定是用继承还是用组合时,问问自己是不是需要向上映射到基类。如果不需要,
就用组合(成员对象)而不用继承。
16. 有时我们为了访问基类中的p r o t e c t e d成员而采用继承。这可能导致一个可察觉的对多
重继承的需求。如果我们不需要向上映射,首先导出一个新类来完成保护成员的访问,然后把
这个新类作为一个成员对象,放在需要用到它的所有对象中去。
17. 一个典型的基类仅仅是它的派生类的一个接口。当我们创建一个基类时,缺省情况下
让成员函数都成为纯虚函数。析构函数也可以是纯虚函数(强制派生类对它重新定义),但记
住要给析构函数一个函数体,因为继承关系中所有的析构函数总是被调用。
18. 当我们在类中放一个虚函数时,让这个类的所有函数都成为虚函数,并在类中定义一
个虚析构函数。
19. 用数据成员表示值的变化,用虚函数表示行为的变化。