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

 

从代码的角度而言，我以为计算机言语都不可难免的处理以下两个问题：

 

 1.为了构建大型的程序，需求将代码模块化。C++中，由类的封装来完成。

 

 2.为了减少代码的冗余，需求完成代码共享。C++中，由类的继承和多态来完成。

 

一、封装

 

C言语中，代码之间的关系都是函数式的调用。这里面牵扯到对数据的操作，若操作的都是部分变量，那一切都安定了。但若是几个函数操作同一个非部分变量，思索到模块化，那么就要将变量和操作变量的函数整合在一同，这就是C++中的封装。

 

C++里面引入了class的概念，目的是封装数据和数据上的操作，无极4官网使其成为一个独立的模块。若是将这个独

 

图1

 

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

 

图2

 

状况一，只需求封装就足够了。处置状况二、三、四时，为了思索代码共享，需求引入继承机制。

 

二、继承

 

我们先思索状况二，由于A和B有公共代码（成员函数或者是成员变量），故通常思索将公共的局部定义为class C，然后由A、B去继承它。

 

图3

 

关于状况三、四，我们不需求演化，直接让A继承B，或者B继承A即可。

 

若，此时引入class D，那么状况就会复杂很多。简单期间，以状况二为扩展，加入无极4思索添加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.没必要提供虚成员变量。父类的成员变量属于存储空间，无极4平台是能够直接用。不像函数，属于代码无法直接交换。

 

2.可能编译器要完成这个会比拟复杂吧。

 

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

 

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

 

 

四、总结

 

      上面的剖析能够看出，引入汇合，只是阐明我试图用一种简单的方式来描绘C++的封装、继承和多态。一切的源头，都是由于在C++中引入了封装机制，也就是传说中的面向对象。继承和多态都是随之而来的，顺着这条途径走下去，你会发现C++里面的变量的可视性（public， protected， private）等都是源自于上面描绘的汇合之间的关系。而一切的这些，只是用来处理两个问题：模块化和代码共享。