通过前两篇博文,我已经将多态的前提条件总结得七七八八了。这一篇开始正式展开讲多态,以及我们为什么要使用多态。
引用百度百科的定义:
多态(Polymorphism)按字面的意思就是“多种状态”。在面向对象语言中,接口的多种不同的实现方式即为多态。引用Charlie Calverts对多态的描述——多态性是允许你将父对象设置成为一个或更多的他的子对象相等的技术,赋值之后,父对象就可以根据当前赋值给它的子对象的特性以不同的方式运作(摘自“Delphi4 编程技术内幕”)。简单的说,就是一句话:允许将子类类型的指针赋值给父类类型的指针。
我的理解是:子类可以通过父类的指针或者引用,调用子类重写父类的虚函数,以达到一个类型多种状态的效果。
这听起来好像没有什么,我可以直接通过子类的对象调用成员函数不就行了,为啥还要舍近求远将其赋值到一个父类指针再调用呢?起初学习的时候我也不懂为什么,直到后来我遇到了一个很典型的例子才恍然大悟,这个例子我会在下面讲到。
前面也零零散散地介绍了C++多态的条件,这里总结一下:
需要上转型是Java多态的条件,C++主要是通过使用父类的指针或者引用来实现的,也可以认为是一种上转型吧。正是因为使用了父类的指针或者引用,才使得他能够调用子类的虚函数,而不是像上一篇的上转型导致的静态绑定,最终调用的是父类的虚函数。我们通过以下代码来回顾一下:
class base
{
public:
virtual void do_something() //有虚函数
{
cout << "I'm base class" << endl;
}
};
class derived : public base //有继承
{
public:
void do_something() //子类重写了父类的虚函数
{
cout << "I'm derived class" << endl;
}
};
void fun1(base &b) //父类的引用
{
b.do_something();
}
void fun2(base *b) //父类的指针
{
b->do_something();
}
void fun3(base b)
{
b.do_something();
}
int main() {
derived d;
fun1(d); //I'm derived class
fun2(&d); //I'm derived class
fun3(d); //I'm base class
return 0;
}
fun1()和fun2()实现的过程都是动态绑定的,即运行时才动态确定要调用哪个函数。那他究竟是怎么实现的?
大家还记得虚类的对象是有一个vptr,多个同类对象的vptr指向同一个vtable。动态绑定就是通过这个vptr间接寻址来实现的。虽然子类对象被赋值到了父类的指针,但是对象的vptr是没有改变的,他指向的还是子类的vtable。 所以父类指针去调用某个虚函数的时候,就会去vtable里面找函数入口,那找到的自然是子类的函数入口。所以他不是在编译期间就确定的,而是在代码运行到那一行的时候才找到的函数入口。
那为什么只有指针或者引用才能达到这个效果呢?《深度探索C++对象模型》这本书对此有这样一个解释:
一个pointer或一个reference之所以支持多态,是因为它们并不引发内存任何与类型有关的内存委托操作。会受到改变的,只有它们所指向内存的大小和解释方式而已。
这样读起来有点拗口,简单讲就是指针或者引用的赋值并不会改变原对象内存里的内容,他只会改变对内存大小及内容的解释方式。举个简单的例子:我将int变量的地址赋值给了char型指针,char型指针才不管原来的变量是什么,他对外只解释一个字节的内容。
同理可知,子类对象的内存内容并没有发生改变,那么对象的vptr还是指向子类的vtable,所以调用的还是子类的的成员函数。而简单的上转型并不会有这样的效果,他会对内存进行重新分配。
另外说一下,只用C++有静态绑定这个概念,其他面向对象类的语言都是动态绑定。可以看出C语言的知识是很细致入微的。
到此其实多态已经讲完了,铺垫了这么多前置知识,其实多态就这么一点点。我主要还是想讲讲为什么要使用多态,只有知道了为什么,才能使我们在设计代码的时候考虑得到如何运用这个知识点。我们用一个游戏的例子来说明为什么。
游戏的描述如下:
我们先来实现怪物类:
class wolf //狼人类
{
public:
wolf(int hp, int ack)
: hp(hp)
, ack(ack)
{}
bool damage(int dm)
{
if (this->hp <= 0) return false;
this->hp -= dm;
return false;
}
bool attack(hero &hr)
{
return hr.damage(this->ack);
}
private:
int hp;
int ack;
};
class zombie
{
public:
zombie(int hp, int ack)
: hp(hp)
, ack(ack)
{}
bool damage(int dm)
{
if (this->hp <= 0) return false;
this->hp -= dm;
return false;
}
bool attack(hero &hr)
{
return hr.damage(this->ack);
}
private:
int hp;
int ack;
};
class witch
{
public:
witch(int hp, int ack)
: hp(hp)
, ack(ack)
{}
bool damage(int dm)
{
if (this->hp <= 0) return false;
this->hp -= dm;
return false;
}
bool attack(hero &hr)
{
return hr.damage(this->ack);
}
private:
int hp;
int ack;
};
然后我们来实现英雄类:
class hero
{
public:
hero(int hp, int ack)
: hp(hp)
, ack(ack)
{}
bool damage(int dm)
{
if (this->hp <= 0) return false;
this->hp -= dm;
}
bool attack(wolf &wf)
{
return wf.damage(this->ack);
}
bool attack(zombie &zb)
{
return zb.damage(this->ack);
}
bool attack(witch &wt)
{
return wt.damage(this->ack);
}
private:
int hp;
int ack;
};
我们发现,同样逻辑的attack()函数,我们需要实现三次。如果后期游戏要增添新的怪物,我们还得继续写attack()函数。 这其实还是一种面向过程的思想,并不是说写几个类出来就是面向对象了。而且这也完全不符合我们程序猿的编程习惯,我们程序猿不喜欢重复的东西。欸,这个时候多态就能发挥他的作用了。
我们来定义怪物们的基类:
class monster
{
public:
virtual bool damage(int dm) = 0;
virtual bool attack(hero &hr) = 0;
};
之前说了,我们并不关心这个基类的虚函数具体是怎么实现的,那么我们就可以将其声明为纯虚类。然后让怪物都继承这个基类,实现上面这两个函数就可以了。这样我们就可以将hero类改造成这样:
class hero
{
public:
hero(int hp, int ack)
: hp(hp)
, ack(ack)
{}
bool damage(int dm)
{
if (this->hp <= 0) return false;
this->hp -= dm;
}
bool attack(monster &ms) //参数修改为monster类一定要用指针或者引用
{
return ms.damage(this->ack);
}
private:
int hp;
int ack;
};
这样代码是不是就简洁很多。而且根据多态的性质,不同的怪物会调用其各自的damage()函数。以后要是新增怪物,只要继承和实现虚基类就好了,hero类并不需要进行修改。这就体现了面向对象编程的优势了,这还只是其中之一。
同理,要是有多种英雄,我们同样可以抽象出一个英雄类的虚基类,然后派生出各式各样的英雄,怪物类也不需要重复写多个attack()函数。
有同学还是觉得怪物类的实现还是重复度太高了,这没有体现多态的优势啊。其实不然,前面说到每个子类都应该重写基类的虚函数,是因为不同的子类都应该有他的特别之处, 所以才叫派生嘛。如果子类和子类,或者子类和基类完全一样那就没有必要继承与派生了。
这里重复度高只是因为代码量小,我只是举了个小小的例子,其实在真正的游戏中不同怪物子类的attack()函数和damage()函数的内部细节应该是不一样。比如不同的怪物有不同的攻击特效,有不同的受击效果,有不同的技能冷却时间等等。这些细节都是通过子类去重写基类的虚函数,才得以体现的。
到此为止,我所了解的继承与多态算是总结完毕了。会简单地封装几个类并不是面向对象编程,只有彻底理解了封装、继承与多态,面向对象编程才算是入了个门。只有理解了这些,我们才能开始学习设计模式,才能领悟到设计模式的精髓所在。学设计模式建议大家去看《大话设计模式》这本书,以后有时间我也会在我的博客里总结一些设计模式。