什么情况下应用纯虚类

天大地大妈咪最大 提交于 2019-12-07 07:01:43

前几天跟同事brainstorm,讨论一个关于纯虚类的使用问题,挺有意思。回来心中久久不能平静,写出来一吐为快。

不论在C++中还是C#中,纯虚类都是不能实例化的,这是因为纯虚类其实是一个对业务类型的一种高度抽象,本质上是不存在这种东西的,所以也就不能实例化它。对于C++中只要类中含有一个纯虚函数就是纯虚类,而C#中是abstract修饰的类就是纯虚类,即使类中没有虚方法也可以是纯虚类,在这里我觉得C#的纯虚类没有C++的严谨,如果纯虚类中没有纯虚方法的话,那有何意义。

明白了纯虚类的原理,那纯虚类应该肯定需要被别的类继承的,因为如果不继承的话,它自己本身也不能实例化,就没有存在的意义了,所以它肯定是需要被继承的。那它需不需要含有一个或者多个纯虚方法呢?答案是肯定的,因为既然纯虚类是需要被继承的,那没有纯虚方法又有何意义。没有纯虚方法它就应该是可以实例化的,那就没有必要将其设定为纯虚类的,这也是我吐槽C#的abstract的一个原因。

有了纯虚类一定要有纯虚方法的这个基础,那就可以想象纯虚类的业务场景应该是下面这个样子的

    abstract class Goods
    {
        public int GetPrice()
        {
            int price = 0;
            //do some standard things
            price = this.CaculatePrice();
            //do some other steps
            return price;
        }


        protected abstract int CaculatePrice();
    }

我们有一类商品,它们都有一些统一的步骤需要做,先预处理,然后计算价格,这个计算价格是每种商品不一样的,最后还要统一再处理下,对一个售货员来说它其实并不关心这是什么商品有什么特性,她只关心这个商品的价格,如果购物车中有多个商品,计算出所有商品的总价格。所以一般会构建一个商品,它没有任何意义,只是将所有商品标准化东西统一起来,将不同的东西抽象为纯虚方法,这样不同的商品就可以只关心它是如何计算价格的,其它不同的部分交给虚基类来处理。这个是比较经典的业务场景,这里虚基类中可能会有多个public的方法,这些方法可以调用纯虚方法也是可以的。总之到最后Goods的使用者是直接调用Goods索引,而不是操作具体的商品类。这种情况一般纯虚类中的纯虚方法一般都是private或者protected(在C++中纯虚函数可以是private、protected和public,但是在C#中纯虚函数只能是protected和public),因为Goods的使用者一般不会直接操作商品内部的CaculatePrice的,这个应该是需要对使用者隐藏的。设成protected是有些时候需要对Goods再进行抽象,这类商品有它特定的使用者,这个时候它又需要调用Goods的方法,这种情况就开发成为protected,比如有一类商品,它们需要提供另外一种方法,计算另外一种类型的价格,但是这种计算方法又是依赖商品的CaculatePrice的结果,继承类需要再写一种方法调用基类的CaculatePrice的方法,如果是private,继承类就没有办法访问,此时就需要将其修改成为protected。

看样子纯虚类中的纯虚方法是不能为public的,一般是private或者protected的,那是否可以是public呢?答案是可以的。针对上面的例子,假设每种商品没有统一的步骤,计算方法各不一样,没有统一的步骤,那这个时候就需要将GetPrice改成纯虚函数,但是这里需要考虑的另外一个问题就是当一个纯虚类中有一个public的纯虚方法,要考虑这个纯虚方法是否是一种interface(这个是C#才有C++中没有的,这个是一个亮点,将is a和支持的方法隔离开来,因为is a的关系太强了),在这个例子我觉得还是纯虚类比较合适,interface不大合适。interface更多的像是一种技能,现实生活中不好想象这样的例子,在基础类库中的IEnumerator这个接口,这个是linq实现的基础,它就是一个典型的接口而不应该实现为纯虚类,list,array和dict它们没有公共关系,不好抽象出来一个基类来实现is a的关系,但是都需要支持遍历数据结构中所有元素的方法,所以都实现IEnumerator的接口,所以interface更像一种技能。

在实际开发过程中需求往往是经常渐进,一开始我们并不知道要设计一个纯虚类,更多的情况是一开始只有一种商品,设计了Goods,然后有另外一种商品,它们有很大的共性,于是将共性提出来,让第二个商品继承第一个商品,其实此时就应该考虑纯虚类的,如果未来看得出来有更多同类的商品出现的话,应该重构一个纯虚基类出来,但是暂时没有让商品2继承商品1没问题,因为我觉得增加一个纯虚基类出来,而且未来还不知道能不能用上,没有必要,因为增加纯虚基类意味着强类型,将来很难再refactor,第二类太多对代码的维护成本也是很高的,基于done is enough的原则,上面直接将商品2继承商品1没有问题,即使看上去两个不应该有继承关系,所以此时为了更好的解决这个问题,可以考虑将商品1改个名字,让它们的继承关系合法化。当商品越来越多的时候大多时候是不会重构出纯虚基类的,因为随着代码的不断增加,维护的成本会指数级增加,而且是修改一个基类,impact会比较大,一般也不会refactor一个纯虚基类。除非整个代码需要重构,可以考虑这么做,如果没有的话,这个代码结构不应该进行重构。所以纯虚基类一般都是代码整体重构的产物,当然如果在需求提出的时候就已经明确那是更好的。

在实际代码中我们会经常遇到一个虚方法是一个空函数的,那什么情况下会将一个虚方法设定为一个空函数呢?

空函数存在的价值是它是有意义的才可以,比如针对上面Goods类,假设它不是纯虚类,只是一个基类,如果有种商品就是没有价格,比如赠品,CalculatePrice直接返回0,没有任何计算,它的子类商品都有自己的计算价格方法,可以重写这个方法。所以说针对空函数的话,如果有意义才可以,一般不需要将其设成空函数,没有意义就可以直接将其改成纯虚方法。


总之:

纯虚类中是一定要有纯虚函数的,如果是私有纯虚方法那这个方法肯定是被纯虚类中其它public调用的,如果纯虚方法是public的时候是语义上更是is a的关系决定的,但是这个时候需要看看这个方法是否也算是has的方法,如果更多的是has的方法,需要考虑将这个方法改成interface,这个只有c#中才有这种功能,c++中是没有的,只是一个纯虚接口类而已。




易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!