了解C++的装、继承和多型

近期重新看了一下C++，一是感觉清晰了许多，二是觉得若是换个角度看的话，会有不一样的体会，并且也容易记住C++中的一些特性。本文就试图将集合论中的相关知识引入到C++的封装、继承、多型上，让我们对它有个重新的认识。

从程式码的角度而言，我认为计算机语言都不可不免的解决以下两个问题：

 1.为了构建大型的程式，需要将程式码模组化。C++中，由类的封装来实现。

 2.为了减少程式码的冗余，需要实现程式码共享。C++中，由类的继承和多型来实现。

一、封装

C语言中，程式码之间的关系都是函式式的呼叫。这里面牵扯到对资料的操作，若操作的都是区域性变数，那一切都太平了。但若是几个函式操作同一个非区域性变数，考虑到模组化，那么就要将变数和操作变数的函式整合在一起，这就是C++中的封装。

C++里面引入了class的概念，目的是封装资料和资料上的操作，使其成为一个独立的模组。若是将这个独立的模组（程式码和资料）想象成集合，那个class A的集合为：

图1

此时若再引入一个class B，则有下面四种可能性，情况三、四实际上类似。

图2

情况一，只需要封装就足够了。处理情况二、三、四时，为了考虑程式码共享，需要引入继承机制。

二、继承

我们先考虑情况二，由于A和B有公共程式码（成员函式或者是成员变数），故通常考虑将公共的部分定义为class C，然后由A、B去继承它。

图3

对于情况三、四，我们不需要演变，直接让A继承B，或者B继承A即可。

若，此时引入class D，那么情况就会复杂很多。简单期间，以情况二为扩充套件，考虑新增class D后的某一种。后续你会发现，情况三、四类似。

图4

此时，最合理的方式是引入四个类，class E, class F, class G, class H，如下图。E为基类，F、G、H为一级子类、A、B、D为二级子类。

图5

但是，这种解决方案有问题：

1.若是再新增class I，class J，那复杂度就可想而知了。

2.虽然程式码冗余是消除了，但是引入了四个类，也着实有点多，更严重的话会导致“类泛滥”。

为了能统一解决新增的类D，我们将图四拆分成D和A，以及D和B的关系。这样就转化为图二中的一种：情况二。

图6

图六中，class H表示D和A的公共部分，class G表示D和B的公共部分。此种解法虽然有程式码冗余，但简单了许多，事实上，我们很多时候处理类，就是这么处理的。

在这种情况下，若是新增class I，class J，都可以转化为：新新增类和已有类之间的单独关系，即图二中的四种情况。

同时，也可以发现，我们无法在类的继承结构中完全消除程式码冗余，原因是多个类的情况下，实在是比较复杂。

当我们在使用这些包含继承结构的类的时候，考虑图二的情况三，若B继承自A，那么实际上B也可以当A用的，这很好理解，本来A就是B的一部分。但若是，想让A代表B呢（实际上就是B物件，只是用的时候当A用），为了完美解决这个问题，就要引入多型了。

三、多型

前面的分析可知，类之间的关系都可以简化为图二的情况。图二的情况三中，A当B用（实际上只有B物件）又分为以下三种情况。第三种情况有点别扭，可能是需求决定的吧。

1.使用B中的A部分。直接使用A操作即可。

2.使用B中的非A部分。需要将A转化为B才可使用。

3.B覆盖定义A的公共界面或者成员变数。当B作为A使用的时候，A中的公共界面或者成员变数是在非A中的，实现这一机制的就是多型。

C++中，基类定义虚拟函式，子类可以重新实现它，以实现多型。令人奇怪的是，没有虚成员变数的概念，我觉得可能有以下几个原因：

1.没必要提供虚成员变数。父类的成员变数属于储存空间，是可以直接用。不像函式，属于程式码无法直接替换。

2.可能编译器要实现这个会比较复杂吧。

3.封装的概念是少暴露成员变数，只暴露界面。因此，好的类的设计是没有公共的成员变数的，也就不存在虚成员变数一说了。

但是，从完整性的角度而言，应该提供虚成员变数的。

四、总结

      上面的分析可以看出，引入集合，只是说明我试图用一种简单的方式来描述C++的封装、继承和多型。所有的源头，都是因为在C++中引入了封装机制，也就是传说中的面向物件。继承和多型都是随之而来的，顺着这条路径走下去，你会发现C++里面的变数的可视性（public, protected, private）等都是源自于上面描述的集合之间的关系。而所有的这些，只是用来解决两个问题：模组化和程式码共享。