近期重新看了一下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）等都是源自于上面描述的集合之间的关系。而所有的这些，只是用来解决两个问题：模块化和代码共享。