Effective C++笔记:继承与面向对象设计
2014-05-29 11:23 ☆Ronny丶 阅读(1188) 评论(1) 编辑 收藏 举报关于OOP
博客地址:http://www.cnblogs.com/ronny 转载请注明出处!
1,继承可以是单一继承或多重继承,每一个继承连接可以是public、protected或private,也可以是virtual或non-virtual。
2,成员函数的各个选项:virtual或non-virtual或pure-virtual。
3,成员函数和其他语言特性的交互影响:缺省参数值与virtual函数有什么交互影响?继承如何影响C++的名称查找规则?设计选项有如些?如果class的行为需要修改,virtual函数是最佳选择吗?
4,public继承意味着“is-a”。
5,virtual函数意味着“接口必须被继承”,non-virtual意味着“接口和实现都必须被继承”。
条款32:确定你的public继承塑模出is-a关系
“public继承”意味着is-a。适用于base classes身上的每一件事情一定也适合于derived class身上,因为每个derived classes对象也都是一个base classes对象。
上面这种关系听起来颇为简单,但有时候你的直觉可能会误导你,比如,企鹅是一种鸟,这是事实。鸟可以飞,这也是事实,但是如果在用类描述时把企鹅定义为鸟的public继承则会出问题,比如给基类定义fly函数。
条款33:避免遮掩继承而来的名称
derived classes内的名称会遮掩base classes内的名称。在public继承下从来没有人希望如些。
// 博客地址:http://www.cnblogs.com/ronny/ 转载请注明出处! class Base { private: int x; public: virtual void mf1() = 0; virtual void mf1(int); virtual void mf2(); void mf3(); void mf3(double); }; class Derived :public Base { public: virtual void mf1(); //屏蔽了Base里的mf1(int) void mf3(); // 屏蔽了Base里的mf3 void mf4(); };
Derived d; int x; d.mf1(); //ok,调用Derived::mf1 d.mf1(x); //error,因为Derived::mf1遮掩Base=::mf1 d.mf2(); //ok,调用Base::mf2 d.mf3(); //ok,调用Derived::mf3 d.mf3(x); // error,因为Derived::mf3遮掩了Base::mf3
Derived内的函数遮掩了Base内所有的同名函数。当然实现中如果是一种public继承,则是一定需要同理继承重载函数的,因为必须符合is-a关系。
我们可以用using声明式达成目标:
class Derived :public Base { public: using Base::mf1; using Base::mf3; virtual void mf1(); void mf3(); void mf4(); };
Derived d; int x; d.mf1(); //ok,仍然调用Derived::mf1 d.mf1(x); //现在没有问题了 d.mf2(); //ok,调用Base::mf2 d.mf3(); //ok,仍然调用Derived::mf3 d.mf3(x); //没有问题了
我们还可以使用交换函数来完成这个功能:有时候我们并不想继承base classes的所有函数。
class Derived :private Base { public: virtual void mf1() // 转交函数 { Base::mf1(); } };
条款34:区分接口继承和实现继承
接口继承和实现继承不同。在public继承之下,derived classes总是继承base class的接口。
pure virtual函数只具体指定接口继承
简朴的(非纯)impure virtual函数具体指定接口继承及缺省实现继承。
non-virtual函数具体指定接口继承以及强制性实现继承
条款35:考虑virtual函数以外的其他选择
这条款谈了两种设计模式,鼓励我们多思考的。
以游戏中的人物设计继承体系为例子,不同的人物有不同的计算健康指数的方法,就叫healthValue函数吧,很自然的就会想到设计一个基类,把healthValue函数设计为virtual的用于继承。
此条款提供了两种不同的思路,用于virtual替代方案:
1. Template Method模式,由Non-Virtual Interface手法实现。
具体到以上的例子就是大概如下:
class GameCharacter { public: int healthValue() const { // ... int retVal = doHealthValue(); // ... return retVal; } private: virtual int doHealthValue() const { } };
其实最先提的把healthValue设计为virtual的方法也是Template Method模式,而这里就是保留healthValue为public,而实现为private virtual(当然这里是可以protected的),这样的好处在于其中的前后“...”(省略号),这部分可以进行一些类似检查、调整的操作,保证doHealthValue()在一个适当的场景下调用。而且子类也可以继承实现private virtual成员函数。
2. Strategy模式,这一模式令实现方法是个变量,就算是同一个对象在不同的时段也可以有不同的实现方法。但这里都有个约束,就是对私有成员变量的访问限制。
a) Function Pointers实现,此种实现手法的约束是只能是函数,而且形式受函数的签名(参数数量,参数类型,返回类型)的约束。
b) tr1::function实现,摆脱了a)的约束,支持隐式类型转换,还支持函数对象或者是成员函数(通过std::tr1::bind实现)
c) 古典实现,其实就是对象实体是一类,而实现方法是另一类。
条款36:绝对不重新定义继承而来的non-virtual函数
当派生类中重新定义了基类中的non-virtual函数时,如果用指向基类类型的指针(实际指向派生类对象)来访问该non-virtual函数时,访问的是基类对象的non-virtual函数。
造成上面行为的原因是,non-virtual是静态绑定的,区别于virtual函数的动态绑定。
条款37:绝不重新定义继承而来的缺省参数值
virtual函数系动态绑定的,而缺省参数值是静态绑定的。
所谓对象的静态类型:在程序中被声明时被采用的类型。而对象的动态类型是指“目前所指对象的类型”,也就是说,动态类型可以表现出一个对象将会有什么行为。
class Shape { public: enum ShapeColor{ Red, Green, Blue }; virtual void draw(ShapeColor color = Red)const = 0; }; class Rectangle :public Shape { public: virtual void draw(ShapeColor color = Green)const = 0; };
上面的代码中,如果我们定义了一个类型为Shape*的指针指向Rectangle。
Shape* ps=new Rectangle;
ps->draw();
我们的实际愿望可能是希望让draw的默认参数为Green,但是实际上确是Red,因为默认参数是静态绑定的。
也许你可能会想让派生类的中virtual函数和base类中保持一致。但是下面的代码显然也是不可行的。
class Shape { public: enum ShapeColor{ Red, Green, Blue }; virtual void draw(ShapeColor color = Red)const = 0; }; class Rectangle :public Shape { public: virtual void draw(ShapeColor color = Red)const = 0; };
上面不仅会产生代码重复,而且带来了相依性(如果Shape内的缺省参数变了,所有派生类的virtual函数缺省值都要修改)。
聪明的做法是考虑替代设计,如条款35中的一些virutal函数的替代设计,其中之一是NVI手法,令base class内的一个public non-virtual函数调用private virtual函数。
class Shape { public: enum ShapeColor{ Red, Green, Blue }; virtual void draw(ShapeColor color = Red)const { doDraw(color); } private: virtual void doDraw(ShapeColor color)const = 0; }; class Rectangle :public Shape { private: virtual void doDraw(ShapeColor color)const; };
条款38:通过复合塑模出has-a或“根据某物实现出”
复合或包含意味着has-a。如果我们想设计一个自己的set,我们思考后觉得可以用list来实现它,但是如果我把它设计出list的一个派生类,就会有问题,因为父类的所有行为在派生类都是被允许的,而list允许元素重复,而set则显然不行,所以set与list之间不符合is-a关系,我们可以把list设计为set的一个成员,即包含关系(has-a)。
条款39:明知而审慎地使用private继承
private继承意味着is-implemented-in-terms of(根据某物实现)。它通常比复合的级别低。但是当derived class需要访问protected base class的成员,或需要重新定义继承而来的virtual函数时,这么设计是合理的。
和复合不同,private继承可以造成empty base最优化。这对致力于“对象尺寸最小化”的程序库开发者而言,可能很重要。
class Empty{}; class HoldsAnInt { private: int x; Empty e; };
这时候你会发现sizeof(HoldsAnInt)>sizeof(int),因为一些内存对齐的要求。
而如果是:
class HoldsAnInt :private Empty{ private: int x; };
这时候几乎可以肯定:sizeof(HoldsAnInt)==sizeof(int)。
条款40:明智而审慎地使用多重继承
使用多重继承就要考虑歧义的问题(成员变量或者成员函数的重名)。
最简单的情况的解决方案是显式的调用(诸如item.Base::f()的形式)。
复杂一点的,就可能会出现“钻石型多重继承”,以File为例:
class File { ... } class InputFile : public File { ... } class OutputFile : public File { ... } class IOFile : public InputFile, public OutputFile { ... }
这里的问题是,当File有个filename时,InputFile与OutputFile都是有的,那么IOFile继承后就会复制两次,就有两个filename,这在逻辑上是不合适的。解决方案就是用virtual继承:
class File { ... } class InputFile : virtual public File { ... } class OutputFile : virtual public File { ... } class IOFile : public InputFile, public OutputFile { ... }
这样InputFile与OutputFile共享的数据就会在IOFile中只保留一份了。
但是virtual继承并不常用,因为:
1. virtual继承会增加空间与时间的成本。
2. virtual继承会非常复杂(编写成本),因为无论是间接还是直接地继承到的virtual base class都必须承担这些bases的初始化工作,无论是多少层的继承都是。
请记住
多重继承比单一继承复杂。它可能导致新的歧义性,以及对virtual继承的需要。
virtual继承会增加大小、速度、初始化(赋值)复杂度等等成本。如果virtual base classes不带任何数据,将是最具实用价值的情况。
多重继承的确有正当用途。其中一个情节涉及“public继承某个Interface class”和“private继承某个协助实现的class”的两相组合。