高质量c++编程指南-第10部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！


Base：：operate　=（other）； //　因为不能直接操作私有数据成员

//（3）对派生类的数据成员赋值
m_x　=　other。m_x；
m_y　=　other。m_y；
m_z　=　other。m_z；

//（4）返回本对象的引用
return　*this；
｝

9。9　一些心得体会
　　有些C＋＋程序设计书籍称构造函数、析构函数和赋值函数是类的〃Big…Three〃，它们的确是任何类最重要的函数，不容轻视。
　　也许你认为本章的内容已经够多了，学会了就能平安无事，我不能作这个保证。如果你希望吃透〃Big…Three〃，请好好阅读参考文献＇Cline＇　＇Meyers＇　＇Murry＇。



第10章　类的继承与组合

　　对象（Object）是类（Class）的一个实例（Instance）。如果将对象比作房子，那么类就是房子的设计图纸。所以面向对象设计的重点是类的设计，而不是对象的设计。
　　对于C＋＋程序而言，设计孤立的类是比较容易的，难的是正确设计基类及其派生类。本章仅仅论述〃继承〃（Inheritance）和〃组合〃（Composition）的概念。
　　注意，当前面向对象技术的应用热点是COM和CORBA，这些内容超出了C＋＋教材的范畴，请阅读COM和CORBA相关论著。
10。1　继承
　　如果A是基类，B是A的派生类，那么B将继承A的数据和函数。例如：
class　A
　　｛
　　public：
void　　Func1（void）；
void　　Func2（void）；
｝；

　　class　B　：　public　A
　　｛
　　public：
void　　Func3（void）；
void　　Func4（void）；
｝；

main（）
　　｛
B　　b；
b。Func1（）； //　B从A继承了函数Func1
b。Func2（）； //　B从A继承了函数Func2
b。Func3（）；
b。Func4（）；
　　｝
　　
　　这个简单的示例程序说明了一个事实：C＋＋的〃继承〃特性可以提高程序的可复用性。正因为〃继承〃太有用、太容易用，才要防止乱用〃继承〃。我们应当给〃继承〃立一些使用规则。
　　
*　【规则10…1…1】如果类A和类B毫不相关，不可以为了使B的功能更多些而让B继承A的功能和属性。不要觉得〃白吃白不吃〃，让一个好端端的健壮青年无缘无故地吃人参补身体。
*　【规则10…1…2】若在逻辑上B是A的〃一种〃（a　kind　of　），则允许B继承A的功能和属性。例如男人（Man）是人（Human）的一种，男孩（Boy）是男人的一种。那么类Man可以从类Human派生，类Boy可以从类Man派生。
class　Human
　　｛
。。。
　　｝；
class　Man　：　public　Human
　　｛
。。。
　　｝；
class　Boy　：　public　Man
　　｛
。。。
　　｝；

*　注意事项
　　【规则10…1…2】看起来很简单，但是实际应用时可能会有意外，继承的概念在程序世界与现实世界并不完全相同。
　　例如从生物学角度讲，鸵鸟（Ostrich）是鸟（Bird）的一种，按理说类Ostrich应该可以从类Bird派生。但是鸵鸟不能飞，那么Ostrich：：Fly是什么东西？
class　Bird
｛
public：
virtual　void　Fly（void）；
。。。
｝；

class　Ostrich　：　public　Bird
｛
。。。
｝；

　　例如从数学角度讲，圆（Circle）是一种特殊的椭圆（Ellipse），按理说类Circle应该可以从类Ellipse派生。但是椭圆有长轴和短轴，如果圆继承了椭圆的长轴和短轴，岂非画蛇添足？
所以更加严格的继承规则应当是：若在逻辑上B是A的〃一种〃，并且A的所有功能和属性对B而言都有意义，则允许B继承A的功能和属性。
10。2　组合
*　【规则10…2…1】若在逻辑上A是B的〃一部分〃（a　part　of），则不允许B从A派生，而是要用A和其它东西组合出B。
　　例如眼（Eye）、鼻（Nose）、口（Mouth）、耳（Ear）是头（Head）的一部分，所以类Head应该由类Eye、Nose、Mouth、Ear组合而成，不是派生而成。如示例10…2…1所示。
　　
class　Eye
｛
　　public：
　　void　　Look（void）；
｝；
class　Nose
｛
　　public：
　　void　　Smell（void）；
｝；
class　Mouth
｛
　　public：
　　void　　Eat（void）；
｝；
class　Ear
｛
　　public：
　　void　　Listen（void）；
｝；
//　正确的设计，虽然代码冗长。　
class　Head
｛
　　public：
void　 Look（void） ｛　　m_eye。Look（）；　　｝
void　 Smell（void） ｛　　m_nose。Smell（）；　　｝
void　 Eat（void） ｛　　m_mouth。Eat（）；　　｝
void　 Listen（void） ｛　　m_ear。Listen（）；　　｝
　　private：
Eye　　 m_eye；
Nose　　 m_nose；
Mouth　　 m_mouth；
Ear　　 m_ear；
｝；
　　示例10…2…1　Head由Eye、Nose、Mouth、Ear组合而成
　　
　　如果允许Head从Eye、Nose、Mouth、Ear派生而成，那么Head将自动具有Look、　Smell、Eat、Listen这些功能。示例10…2…2十分简短并且运行正确，但是这种设计方法却是不对的。
　　
//　功能正确并且代码简洁，但是设计方法不对。
　　class　Head　：　public　Eye；　public　Nose；　public　Mouth；　public　Ear
　　｛
　　｝；
　　示例10…2…2　　Head从Eye、Nose、Mouth、Ear派生而成
　　
　　一只公鸡使劲地追打一只刚下了蛋的母鸡，你知道为什么吗？
　　因为母鸡下了鸭蛋。
　　很多程序员经不起〃继承〃的诱惑而犯下设计错误。〃运行正确〃的程序不见得是高质量的程序，此处就是一个例证。
　　
　　
第11章　其它编程经验
11。1　使用const提高函数的健壮性
　　看到const关键字，C＋＋程序员首先想到的可能是const常量。这可不是良好的条件反射。如果只知道用const定义常量，那么相当于把火药仅用于制作鞭炮。const更大的魅力是它可以修饰函数的参数、返回值，甚至函数的定义体。
　　const是constant的缩写，〃恒定不变〃的意思。被const修饰的东西都受到强制保护，可以预防意外的变动，能提高程序的健壮性。所以很多C＋＋程序设计书籍建议：〃Use　const　whenever　you　need〃。
　　
11。1。1　用const修饰函数的参数
　　如果参数作输出用，不论它是什么数据类型，也不论它采用〃指针传递〃还是〃引用传递〃，都不能加const修饰，否则该参数将失去输出功能。
　　const只能修饰输入参数：　
*　如果输入参数采用〃指针传递〃，那么加const修饰可以防止意外地改动该指针，起到保护作用。
　　例如StringCopy函数：
void　StringCopy（char　*strDestination；　const　char　*strSource）；
其中strSource是输入参数，strDestination是输出参数。给strSource加上const修饰后，如果函数体内的语句试图改动strSource的内容，编译器将指出错误。

*　如果输入参数采用〃值传递〃，由于函数将自动产生临时变量用于复制该参数，该输入参数本来就无需保护，所以不要加const修饰。
　　例如不要将函数void　Func1（int　x）　写成void　Func1（const　int　x）。同理不要将函数void　Func2（A　a）　写成void　Func2（const　A　a）。其中A为用户自定义的数据类型。

*　对于非内部数据类型的参数而言，象void　Func（A　a）　这样声明的函数注定效率比较底。因为函数体内将产生A类型的临时对象用于复制参数a，而临时对象的构造、复制、析构过程都将消耗时间。
　　为了提高效率，可以将函数声明改为void　Func（A　&a），因为〃引用传递〃仅借用一下参数的别名而已，不需要产生临时对象。但是函数void　Func（A　&a）　存在一个缺点：〃引用传递〃有可能改变参数a，这是我们不期望的。解决这个问题很容易，加const修饰即可，因此函数最终成为void　Func（const　A　&a）。
　　以此类推，是否应将void　Func（int　x）　改写为void　Func（const　int　&x），以便提高效率？完全没有必要，因为内部数据类型的参数不存在构造、析构的过程，而复制也非常快，〃值传递〃和〃引用传递〃的效率几乎相当。
问题是如此的缠绵，我只好将〃const　&〃修饰输入参数的用法总结一下，如表11…1…1所示。

　　对于非内部数据类型的输入参数，应该将〃值传递〃的方式改为〃const引用传递〃，目的是提高效率。例如将void　Func（A　a）　改为void　Func（const　A　&a）。
　　
　　对于内部数据类型的输入参数，不要将〃值传递〃的方式改为〃const引用传递〃。否则既达不到提高效率的目的，又降低了函数的可理解性。例如void　Func（int　x）　不应该改为void　Func（const　int　&x）。
　　
表11…1…1　〃const　&〃修饰输入参数的规则

11。1。2　用const修饰函数的返回值
*　如果给以〃指针传递〃方式的函数返回值加const修饰，那么函数返回值（即指针）的内容不能被修改，该返回值只能被赋给加const修饰的同类型指针。
　　例如函数
const　char　*　GetString（void）；
　　如下语句将出现编译错误：
char　*str　=　GetString（）；
　　正确的用法是
const　char　*str　=　GetString（）；

*　如果函数返回值采用〃值传递方式〃，由于函数会把返回值复制到外部临时的存储单元中，加const修饰没有任何价值。
例如不要把函数int　GetInt（void）　写成const　int　GetInt（void）。
同理不要把函数A　GetA（void）　写成const　A　GetA（void），其中A为用户自定义的数据类型。
如果返回值不是内部数据类型，将函数A　GetA（void）　改写为const　A　&　GetA（void）的确能提高效率。但此时千万千万要小心，一定要搞清楚函数究竟是想返回一个对象的〃拷贝〃还是仅返回〃别名〃就可以了，否则程序会出错。见6。2节〃返回值的规则〃。

*　函数返回值采用〃引用传递〃的场合并不多，这种方式一般只出现在类的赋值函数中，目的是为了实现链式表达。
　　例如
class　A
｛。。。
A　&　operate　=　（const　A　&other）； //　赋值函数
｝；
A　a；　b；　c；　 //　a；　b；　c　为A的对象
。。。
a　=　b　=　c； //　正常的链式赋值
（a　=　b）　=　c； //　不正常的链式赋值，但合法
　　如果将赋值函数的返回值加const修饰，那么该返回值的内容不允许被改动。上例中，语句　a　=　b　=　c仍然正确，但是语句　（a　=　b）　=　c　则是非法的。

11。1。3　const成员函数
任何不会修改数据成员的函数都应该声明为const类型。如果在编写const成员函数时，不慎修改了数据成员，或者调用了其它非const成员函数，编译器将指出错误，这无疑会提高程序的健壮性。
　　以下程序中，类stack的成员函数GetCount仅用于计数，从逻辑上讲GetCount应当为const函数。编译器将指出GetCount函数中的错误。
class　Stack
　　｛
　　public：
void　 Push（int　elem）；
int　 Pop（void）；
int GetCount（void）　　const； //　const成员函数
　　private：
int m_num；
int m_data＇100＇；
　　｝；

int　Stack：：GetCount（void）　　const
　　｛
＋＋　m_num； //　编译错误，企图修改数据成员m_num
　　 Pop（）； //　编译错误，企图调用非const函数
　　 return　m_num；
｝
const成员函数的声明看起来怪怪的：const关键字只能放在函数声明的尾部，大概是因为其它地方都已经被占用了。
11。2　提高程序的效率
　　程序的时间效率是指运行速度，空间效率是指程序占用内存或者外存的状况。
　　全局效率是指站在整个系统的角度上考虑的效率，局部效率是指站在模块或函数角度上考虑的效率。
　　
*　【规则11…2…1】不要一味地追求程序的效率，应当在满足正确性、可靠性、健壮性、可读性等质量因素的前提下，设法提高程序的效率。
　　
*　【规则11…2…2】以提高程序的全局效率为主，提高局部效率为辅。

*　【规则11…2…3】在优化程序的效率时，应当先找出限制效率的〃瓶颈〃，不要在无关紧要之处优化。

*　【规则11…2…4】先优化数据结构和算法，再优化执行代码。

*　【规则11…2…5】有时候时间效率和空间效率可能对立，此时应当分析那个更重要，作出适当的折衷。例如多花费一些内存来提高性能。

*　【规则11…2…6】不要追求紧凑的代码，因为紧凑的代码并不能产生高效的机器码。

11。3　一些有益的建议
*　【建议11…3…1】当心那些视觉上不易分辨的操作符发生书写错误。
我们经常会把〃＝＝〃误写成〃＝〃，象〃｜｜〃、〃&&〃、〃=〃这类符号也很容易发生〃丢1〃失误。然而编译器却不一定能自动指出这类错误。

*　【建议11…3…2】变量（指针、数组）被创建之后应当及时把它们初始化，以防止把未被初始化的变量当成右值使用。

*　【建议11…3…3】当心变量的初值、缺省值错误，或者精度不够。

*　【建议11…3…4】当心数据类型转换发生错误。尽量使用显式的数据类型转换（让人们知道发生了什么事），避免让编译器轻悄悄地进行隐式的数据类型转换。

*　【建议11…3…5】当心变量发生上溢或下溢，数组的下标越界。

*　【建议11…3…6】当心忘记编写错误处理程序，当心错误处理程序本身有误。

*　【建议11…3…7】当心文件I/O有错误。

*　【建议11…3…8】避免编写技巧性很高代码。

*　【建议11…3…9】不要设计面面俱到、非常灵活的数据结构。

*　【建议11…3…10】如果原有的代码质量比较好，尽量复用它。但是不要修补很差劲的代码，应当重新编写。

*　【建议11…3…11】尽量使用标准库函数，不要〃发明〃已经存在的库函数。

*　【建议11…3…12】尽量不要使用与具体硬件或软件环境关系密切的变量。

*　【建议11…3…13】把编译器的选择项设置为最严格状态。

*　【建议11…3…14】如果可能的话，使用PC…Lint、LogiScope等工具进行代码审查。



参考文献
＇Cline＇　Marshall　P。　Cline　and　G