8. 多态（PolyMorphism）

8.1. 浅析多态的意义

如果有几个上似而不完全相同的对象，有时人们要求在向它们发出同一个消息时，它们的反应各不相同，分别执行不同的操作。这种情况就是多态现象。

例如，甲乙丙 3 个班都是高二年级，他们有基本相同的属性和行为，在同时听到上课铃声的时候，他们会分别走向 3 个不同的教室，而不会走向同一个教室。

同样，如果有两支军队，当在战场上听到同种号声，由于事先约定不同，A 军队可能实施进攻，而 B 军队可能准备 kalalok。

又如在 winows 环境下，用鼠标双击一个对象（这就是向对象传递一个消息），如果对象是一个可执行文件，则会执行此程序，如果对象是一个文本文件，由会启动文本编辑器并打开该文件。

C++中所谓的多态(polymorphism)是指，由继承而产生的相关的不同的类，其对象对同一消息会作出不同的响应。多态性是面向对象程序设计的一个重要特征，能增加程序的灵活性。可以减轻系统升级,维护,调试的工作量和复杂度.

8.2. 赋值兼容(多态实现的前提)

8.2.1. 规则

赋值兼容规则是指在需要基类对象的任何地方都可以使用公有派生类的对象来替代。

赋值兼容是一种默认行为，不需要任何的显示的转化步骤。

赋值兼容规则中所指的替代包括以下的情况：

 派生类的对象可以赋值给基类对象。

 派生类的对象可以初始化基类的引用。

 派生类对象的地址可以赋给指向基类的指针。

在替代之后，派生类对象就可以作为基类的对象使用，但只能使用从基类继承的成员。

8.2.2. 代码

#include <iostream>
using namespace std;
class Shape
{
public:
    Shape(int x,int y)
        :_x(x),_y(y){}
    void draw()
    {
        cout<<"draw Shap ";
        cout<<"start ("<<_x<<","<<_y<<") "<<endl;
    }
//private:
protected:
    int _x;
    int _y;
};
class Circle:public Shape
{
public:
    Circle(int _x, int _y,int r)
        :Shape(_x,_y),_r(r){}
    void draw()
    {
        cout<<"draw Circle ";
        cout<<"start ("<<_x<<","<<_y<<") ";
        cout<<"radio r = "<<_r<<endl;
    }
private:
    int _r;
};
int main()
{
    Shape s(3,5);
    s.draw();
    Circle c(1,2,4);
    c.draw();
    s = c;
    s.draw();
    Shape &rs = c;
    rs.draw();
    Shape *ps = &c;
    ps->draw();
    return 0;
}

8.2.3. 补充：
父类也可以通过强转的方式转化为子类。 但存在访问越界的风险

//c = static_cast<Circle>(s); //缺少转化函数
//c.draw();
    Circle * pc = static_cast<Circle*>(&s);
    pc->draw();

8.3. 多态形成的条件
多态行成的条件：
1，父类中有虚函数。
2，子类 override(覆写)父类中的虚函数。
3，通过己被子类对象赋值的父类指针，调用共用接口。
8.3.1. 虚函数
 格式

class 类名
{
    virtual 函数声明;
}

 例举
Shape 类中

virtual void draw()
{
    cout<<"draw Shap ";
    cout<<"start ("<<_x<<","<<_y<<") "<<endl;
}

Circle 类中

void draw()
{
    cout<<"draw Circle ";
    cout<<"start ("<<_x<<","<<_y<<") ";
    cout<<"radio r = "<<_r<<endl;
}

 测试

int main()
{
    Shape s(1,2);
    Circle c(1,2,3);
    Rect r(1,2,3,5);
    Shape *pc = &c;
    pc->draw();
    pc = &r;
    pc->draw();
    return 0;
}

8.3.2. 虚函数小结
1， 在基类中用 virual 声明成员函数为虚函数。类外实现虚函数时，不必再加virtual.
2，在派生类中重新定义此函数称为覆写，要求函数名，返值类型，函数参数个数及类型全部匹配。并根据派生类的需要重新定义函数体。
3，当一个成员函数被声明为虚函数后，其派生类中完全相同的函数（显示的写出）也为虚函数。 可以在其前加 virtual 以示清晰。
4，定义一个指基类对象的指针，并使其指向其子类的对象，通过该指针调用虚函数，此时调用的就是指针变量指向对象的同名函数。
8.3.3. 纯虚函数
 格式

class 类名
{
    virtual 函数声明 = 0;
}

 例举
Shape 类中

virtual void draw() = 0;

Circle 类中

ircle 类中
void draw()
{
    cout<<"draw Circle ";
    cout<<"start ("<<_x<<","<<_y<<") ";
    cout<<"radio r = "<<_r<<endl;
}

 测试

int main()
{
//    Shape s(1,2); //函数纯虚函数的类称为抽象基类
    Circle c(1,2,3);
    Rect r(1,2,3,5);
    Shape *pc = &c;
    pc->draw();
    pc = &r;
    pc->draw();
    return 0;
}

8.3.4. 纯虚函数小结

1. 含有纯虚函数的类，称为抽象基类，不可实列化。即不能创建对象，存在的意义就是被继承，提供族类的公共接口，java 中称为 interface。
2. 纯虚函数只有声明，没有实现，被“初始化”为 0。
3. 如果一个类中声明了纯虚函数，而在派生类中没有对该函数定义，则该虚函数在派生类中仍然为纯虚函数，派生类仍然为纯虚基类。
   

8.3.5. 含有虚函数的析构
含有虚函数的类，析构函数也应该声明为虚函数。在 delete 父类指针的时候，会调用子类的析构函数。

8.3.6. 若干限制
1 只有类的成员函数才能声明为虚函数。
虚函数仅适用于有继承关系的类对象，所以普通函数不能声明为虚函数。2 静态成员函数不能是虚函数
静态成员函数不受对象的捆绑，只有类的信息。
3 内联函数不能是虚函数
4 构造函数不能是虚函数
构造时，对象的创建尚未完成。构造完成后，才能算一个名符其实的对象。5 析构函数可以是虚函数且通常声明为虚函数

8.4. 案例
8.4.1. 覆写–基于qt覆写鼠标事件
 qmainwindow.h

#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
class MainWindow : public QMainWindow
{
    Q_OBJECT
public:
    MainWindow(QWidget *parent = 0);
    ~MainWindow();
    virtual voidmousePressEvent(QMouseEvent * event);
};
#endif // MAINWINDOW_H

 qmainwindow.cpp

#include "mainwindow.h"
#include <QMouseEvent>
#include <QDebug>
#include <iostream>
using namespace std;
MainWindow::MainWindow(QWidget *parent)
        : QMainWindow(parent)
{
    this->setFixedSize(500,300);
}
MainWindow::~MainWindow()
{
}
voidMainWindow::mousePressEvent(QMouseEvent * event)
{
    if(event->button() == Qt::LeftButton)
    {
        qDebug()<<"MouePressEnent "<<event->x()<<""<<event->y()<<""
            <<event->globalX()<<""<<event->globalY()<<endl;
    }
}

 main.cpp

#include "mainwindow.h"
#include <QApplication>
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;
    w.show();
    return a.exec();
}

8.4.2. 虚析构–动物园里欢乐多
 动物类
animal.h

#ifndef ANIMAL_H
#define ANIMAL_H
class Animal
{
public:
    Animal();
    virtual ~Animal();
    virtual void voice() = 0;
};
#endif // ANIMAL_H

animal.cpp

#include "animal.h"
#include <iostream>
using namespace std;
Animal::Animal()
{
    cout<<"Animal::Animal()"<<endl;
}
Animal::~Animal()
{
    cout<<"Animal::~Animal()"<<endl;
}

 狗类
dog.h

dog.h
#ifndef DOG_H
#define DOG_H
#include "animal.h"
class Dog:public Animal
{
public:
    Dog();
    ~Dog();
    virtual void voice();
};
#endif // DOG_H

dog.cpp

#include "dog.h"
#include <iostream>
using namespace std;
Dog::Dog()
{
    cout<<"Dog::Dog()"<<endl;
}
Dog::~Dog()
{
    cout<<"Dog::~Dog()"<<endl;
}
void Dog:: voice()
{
    cout<<"wang wang"<<endl;
}

 猫类
cat.h

#ifndef CAT_H
#define CAT_H
#include "animal.h"
class Cat:public Animal
{
public:
    Cat();
    ~Cat();
virtual void voice();
};
#endif // CAT_H

cat.cpp

#include "cat.h"
#include <iostream>
using namespace std;
Cat::Cat()
{
    cout<<"Cat::Cat()"<<endl;
}
Cat::~Cat()
{
    cout<<"Cat::~Cat()"<<endl;
}
void Cat::voice()
{
    cout<<"miao miao "<<endl;
}

 测试

int main()
{
//     Animal ani; 抽象基类，不能实例化。
    Animal * pa = new Dog;
    pa->voice();
    delete pa;
    cout<<"---------------"<<endl;
    pa = new Cat;
    pa->voice();
    delete pa;
    return 0;
}

8.4.3. 设计模式–听妈妈讲故事
C++中有一种设计原则叫依赖倒置。也是基于多态的。
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
问题由来：类 A 直接依赖类 B，假如要将类 A 改为依赖类 C，则必须通过修改类A的代码来达成。这种场景下，类 A 一般是高层模块，负责复杂的业务逻辑；类B 和类C是低层模块，负责基本的原子操作；假如修改类 A，会给程序带来不必要的风险。

解决方案：将类 A 修改为依赖接口 I，类 B 和类 C 各自实现接口I，类A 通过接口I间接与类 B 或者类 C 发生联系，则会大大降低修改类 A 的几率。
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在c++中，抽象指的是抽象类(c++中称为接口)，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

图示: 依赖倒置原则

传统的过程式设计倾向于使高层次的模块依赖于低层次的模块，抽象层依赖于具体的层次。

依赖倒置原则的核心思想是面向接口编程，我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。代码如下：

#include <iostream>
using namespace std;
class Book
{
public:
    string getContents()
    {
        return "从前有座山，山里有座庙，庙里有个小和沿，要听故事";
    }
};
class Mother
{
public:
    void tellStroy(Book *b)
    {
        cout<<b->getContents()<<endl;
    }
};
int main()
{
    Mother m;
    Book *b = new Book;
    cout<<"Mother start to tell story"<<endl;
    m.tellStroy(b);
    delete b;
    return 0;
}

运行结果：

Mather start to tellstory:
从前有座山，山里有座庙，庙里有个小和沿，要听故事运行良好

假如有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码如下：

class NewsPaper
{
public:
    string getContents()
    {
        return "希拉里，赢得的下一届美国总统大选";
    }
};

这位母亲却办不到，因为她居然不会读报纸上的故事，这太荒唐了，只是将书换成报纸，居然必须要修改 Mother 才能读。假如以后需求换成杂志呢？换成网页呢？还要不断地修改Mother，这显然不是好的设计。原因就是 Mother 与 Book 之间的耦合性太高了，必须降低他们之间的耦合度才行。
我们引入一个抽象的接口 IReader。读物，只要是带字的都属于读物：

class IReader // InterfaceReader
{
public:
    virtual string getContent() = 0;
};

Mother 类与接口 IReader 发生依赖关系，而 Book 和 Newspaper 都属于读物的范畴，他们各自都去实现 IReader 接口，这样就符合依赖倒置原则了，代码修改为：

#include <iostream>
using namespace std;
class IReader
{
public:
    virtual string getContents() = 0;
};
class Book :public IReader
{
public:
    string getContents()
    {
        return "从前有座山，山里有座庙，庙里有个小和沿，要听故事";
    }
};
class NewsPaper:public IReader
{
public:
    string getContents()
    {
        return "希拉里，赢得的下一届美国总统大选";
    }
};
class Mother
{
public:
    void tellStroy(IReader *i)
    {
        cout<<i->getContents()<<endl;
    }
};
int main()
{
    Mother m;
    Book *b = new Book;
    NewsPaper *n = new NewsPaper;
    cout<<"Mother start to tell story"<<endl;
    m.tellStroy(b);
    cout<<"Mother start to tell news"<<endl;
    m.tellStroy(n);
    delete b;
    return 0;
}

运行结果：

Mother start to tell story
从前有座山，山里有座庙，庙里有个小和沿，要听故事
Mother start to tell news
希拉里，赢得的下一届美国总统大选

这样修改后，无论以后怎样扩展 Client 类，都不需要再修改 Mother 类了。这只是一个简单的例子，实际情况中，代表高层模块的 Mother 类将负责完成主要的业务逻辑，一旦需要对它进行修改，引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。
采用依赖倒置原则给多人并行开发带来了极大的便利，比如上例中，原本Mother 类与Book 类直接耦合时，Mother 类必须等 Book 类编码完成后才可以进行编码，因为Mother 类依赖于 Book 类。修改后的程序则可以同时开工，互不影响，因为 Mother 与Book 类一点关系也没有。参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。现在很流行的 TDD 开发模式就是依赖倒置原则最成功的应用。
依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。