近期重新看了一下C++，一是感觉清晰了许多，二是觉得若是换个角度看的话，会有不一样的体会，并且也容易记住C++中的一些特性。本文就试图将集合论中的相关知识引入到C++的封装、继承、多态上，让我们对它有个新的认识。
　　一、封装
　　C语言中，代码之间的关系都是函数式的调用。这里面牵扯到对数据的操作，若操作的都是局部变量，那一切都太平了。但若是几个函数操作同一个非局部变量，考虑到模块化，那么就要将变量和操作变量的函数整合在一起，这就是C++中的封装。
　　C++里面引入了class的概念，目的是封装数据和数据上的操作，使其成为一个独立的模块。若是将这个独立的模块（代码和数据）想象成集合，那个class A的集合为：
　　此时若再引入一个class B，则有下面四种可能性，情况三、四实际上类似。
　　情况一，只需要封装就足够了。处理情况二、三、四时，为了考虑代码共享，需要引入继承机制。
　　二、继承
　　我们先考虑情况二，由于A和B有公共代码（成员函数或者是成员变量），故通常考虑将公共的部分定义为class C，然后由A、B去继承它。
　　对于情况三、四，我们不需要演变，直接让A继承B，或者B继承A即可。
　　若此时引入class D，那么情况就会复杂很多。简单起见，以情况二为扩展，考虑添加class D后的某一种。后续你会发现，情况三、四类似。
　　此时，最合理的方式是引入四個类，class E， class F， class G， class H。E为基类，F、G、H为一级子类、A、B、D为二级子类。
　　但是，这种解决方案有问题：
　　1.若是再添加class I，class J，那复杂度就可想而知了。
　　2.虽然代码冗余是消除了，但是引入了四个类，也着实有点多，更严重的话会导致“类泛滥”。
　　为了能统一解决添加的类D，我们将图四拆分成D和A，以及D和B的关系。这样就转化为图2中的一种：情况二。
　　图6中，class H表示D和A的公共部分，class G表示D和B的公共部分。此种解法虽然有代码冗余，但简单了许多，事实上，我们很多时候处理类，就是这么处理的。
　　在这种情况下，若是添加class I，class J，都可以转化为新添加类和已有类之间的单独关系，即图2中的四种情况。
　　同时，也可以发现，我们无法在类的继承结构中完全消除代码冗余，原因是多个类的情况下，实在是比较复杂。
　　当我们在使用这些包含继承结构的类的时候，考虑图2的情况三，若B继承自A，那么实际上B也可以当A用的，这很好理解，本来A就是B的一部分。但若是想让A代表B呢（实际上就是B对象，只是用的时候当A用），为了完美解决这个问题，就要引入多态了。
　　三、多态
　　由前面的分析可知，类之间的关系都可以简化为图2的情况。图2的情况三中，A当B用（实际上只有B对象）又分为以下三种情况。第三种情况有点别扭，可能是需求决定的吧。
　　1.使用B中的A部分。直接使用A操作即可。
　　2.使用B中的非A部分。需要将A转化为B才可使用。
　　3.B覆盖定义A的公共接口或者成员变量。当B作为A使用的时候，A中的公共接口或者成员变量是在非A中的，实现这一机制的就是多态。
　　C++中，基类定义虚函数，子类可以重新实现它，以实现多态。令人奇怪的是，没有虚成员变量的概念，我觉得可能有以下几个原因：
　　1.没必要提供虚成员变量。父类的成员变量属于存储空间，可以直接用。不像函数，属于代码无法直接替换。
　　2.可能编译器要实现这个会比较复杂吧。
　　3.封装的概念是少暴露成员变量，只暴露接口。因此，好的类的设计是没有公共的成员变量的，也就不存在虚成员变量一说了。但是，从完整性的角度而言，应该提供虚成员变量的。