小酌重构系列[14]——使用多态代替条件判断

概述

有时候你可能会在条件判断中,根据不同的对象类型(通常是基类的一系列子类,或接口的一系列实现),提供相应的逻辑和算法。
当出现大量类型检查和判断时,if else(或switch)语句的体积会比较臃肿,这无疑降低了代码的可读性。
另外,if else(或switch)本身就是一个“变化点”,当需要扩展新的对象类型时,我们不得不追加if else(或switch)语句块,以及相应的逻辑,这无疑降低了程序的可扩展性,也违反了面向对象的OCP原则。

基于这种场景,我们可以考虑使用“多态”来代替冗长的条件判断,将if else(或switch)中的“变化点”封装到子类中。这样,就不需要使用if else(或switch)语句了,取而代之的是子类多态的实例,从而使得代码的可读性和可扩展性提高了——这就是本文要介绍的重构策略“使用多态代替条件判断”。

使用多态代替条件

图说

这个重构策略比较容易理解,下面这幅图演示了它的重构过程(绿色表示重构前,红色表示重构后)。

这个重构也常见于一些设计模式,例如:“策略者模式”(指对象的某个行为,在某个场景中,该行为有不同的实现算法)。

示例

重构前

这段代码定义了4个类,Employee和NonEmployee是Customer的子类,OrderProcessor类根据不同的客户类型和订单商品处理订单折扣。

隐藏代码

public abstract class Customer
{
}

public class Employee : Customer
{
}

public class NonEmployee : Customer
{
}

public class OrderProcessor
{
    public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)
    {
        // do some processing of order
        decimal orderTotal = products.Sum(p => p.Price);

        Type customerType = customer.GetType();
        if (customerType == typeof(Employee))
        {
            orderTotal -= orderTotal * 0.15m;
        }
        else if (customerType == typeof(NonEmployee))
        {
            orderTotal -= orderTotal * 0.05m;
        }

        return orderTotal;
    }
}

可以看到,ProcessOrder()方法的可读性较差,也比较难以维护。
如果某些客户类型不再使用了,它里面的一些分支判断就变成了无效的代码。
如果扩展新的客户类型,ProcessOrder()方法的逻辑需要变更,if else语句块也会越来越大。
我们使用多态代替条件判断来重构。

重构后

重构后,由于DiscountPercentage封装在Customer类和其子类中了,所以ProcessOrder()方法就无需去判定customer对象的真正类型了。
即使扩展新的Customer类型,ProcessOrder()方法也不用修改,而只需要继承Customer类并实现DiscountPercentage属性,这也符合面向对象的OCP原则。

隐藏代码

public abstract class Customer
{
    public abstract decimal DiscountPercentage { get; }
}

public class Employee : Customer
{
    public override decimal DiscountPercentage
    {
        get { return 0.15m; }
    }
}

public class NonEmployee : Customer
{
    public override decimal DiscountPercentage
    {
        get { return 0.05m; }
    }
}

public class OrderProcessor
{
    public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)
    {
        // do some processing of order
        decimal orderTotal = products.Sum(p => p.Price);

        orderTotal -= orderTotal * customer.DiscountPercentage;

        return orderTotal;
    }
}

【关注】keepfool

时间: 2024-12-24 06:26:22

小酌重构系列[14]——使用多态代替条件判断的相关文章

小酌重构系列[11]&mdash;&mdash;提取基类、提取子类、合并子类

概述 继承是面向对象中的一个概念,在小酌重构系列[7]--使用委派代替继承这篇文章中,我"父子关系"描述了继承,这是一种比较片面的说法.后来我又在UML类图的6大关系,描述了继承是一种"is a kind of"关系,它更偏向于概念层次,这种解释更契合继承的本质.本篇要讲的3个重构策略提取基类.提取子类.合并子类都是和继承相关的,如果大家对继承的理解已经足够深刻了,这3个策略用起来应该会得心应手. 提取基类 定义:如果有超过一个类有相似的功能,应该提取出一个基类,并

小酌重构系列[15]&mdash;&mdash;策略模式代替分支

前言 在一些较为复杂的业务中,客户端需要依据条件,执行相应的行为或算法.在实现这些业务时,我们可能会使用较多的分支语句(switch case或if else语句).使用分支语句,意味着"变化"和"重复",每个分支条件都代表一个变化,每个分支逻辑都是相似行为或算法的重复.当追加新的条件时,我们需要追加分支语句,并追加相应的行为或算法. 上一篇文章"使用多态代替条件判断"中,我们讲到它可以处理这些"变化"和"重复&qu

小酌重构系列目录汇总

为了方便大家阅读这个系列的文章,我弄了个目录汇总. 方法.字段重构 移动方法 (2016-04-24) 提取方法.提取方法对象 (2016-04-26) 方法.字段的提升和降低 (2016-05-01) 分解方法 (2016-05-02) 为布尔方法命名 (2016-05-03) 引入对象参数 (2016-05-04) 类.接口重构 使用委派代替继承 (2016-05-07) 提取接口 (2016-05-08) 解除依赖 (2016-05-09) 分离职责 (2016-05-11) 提取基类.提

小酌重构系列[20]&mdash;&mdash;用条件判断代替异常

概述 异常处理的关键在于何时处理异常以及如何使用异常,有些开发者会觉得try catch的处理和使用难以把握,于是他们秉承着"您可错杀一千,不可放过一个"的想法,给所有的方法添加try catch. 这种方式会对应用程序造成什么影响吗? 从用户角度出发,用户确实难以察觉到什么,应用程序运行正常,使用的体验好像也没什么差别. 从程序角度出发,大量的try catch会降低代码的可读性,只有在异常触发时才会对程序的性能造成较大的影响. 这两种角度有对错吗? 二者都没有错,第一种角度甚至要远

小酌重构系列[23]&mdash;&mdash;封装条件

概述 当条件判断语句较为复杂时(有多个不同的检查项),就像下面这幅图所表示的,会使得代码的可读性会大打折扣,也难以清晰地传达判断意图. 再者,当判断逻辑变更时,我们不得不去修改if语句里面的判断代码.如果判断写得有问题,则会影响方法的正确性,也会给该方法的单元测试带来一些障碍. 我们可以根据检查项是否需要参数来封装条件,如果检查项不需要参数,则可以将其提取为属性:如果需要参数,则将其提取为方法.本文要讲的重构策略"封装条件"是基于"提取方法"这个重构策略的. 示例

小酌重构系列[22]——尽快返回

概述 阅读文章时,如果某个段落已经传达了关键信息,我们可能就不会逐字逐句地将文章读完,因为我们已经知道了这篇文章的核心内容.与此类似,如果方法中某些条件判断可以得到结果,我们应该尽快返回该结果. 尽快返回可以带来三个好处 节省阅读代码的时间——如果方法能够尽快返回,后面的代码逻辑可以不必阅读.见下图,如果①已经返回了,就不必阅读②部分的代码 避免执行无效的逻辑——如果方法能够尽快返回,后面的代码逻辑就不会被执行.见下图,如果①已经返回了,②部分的逻辑不会被执行 增强代码的可读性 在分解大括号这篇

小酌重构系列[23]——封装条件

当条件判断语句较为复杂时(有多个不同的检查项),就像下面这幅图所表示的,会使得代码的可读性会大打折扣,也难以清晰地传达判断意图. 再者,当判断逻辑变更时,我们不得不去修改if语句里面的判断代码.如果判断写得有问题,则会影响方法的正确性,也会给该方法的单元测试带来一些障碍. 我们可以根据检查项是否需要参数来封装条件,如果检查项不需要参数,则可以将其提取为属性:如果需要参数,则将其提取为方法.本文要讲的重构策略“封装条件”是基于“提取方法”这个重构策略的. 示例 重构前 这个示例中,PerformC

小酌重构系列[12]&mdash;&mdash;去除上帝类

关于上帝类 神说:"要有光",就有了光.--<圣经>.上帝要是会写程序,他写的类一定是"上帝类".程序员不是上帝,不要妄想成为上帝,但程序员可以写出"上帝类".上帝是唯一的,上帝的光芒照耀人间,上帝是很爱面子的,他知道程序员写了"上帝类",抢了他的风头,于是他降下神罚要惩戒程序员.--既然你写了"上帝类",那么就将你流放到艰难地修改和痛苦的维护的炼狱中,在地狱之火中永久地熬炼. 你看,上帝也是有

小酌重构系列[21]&mdash;&mdash;避免双重否定

避免双重否定 在自然语言中,双重否定表示肯定.但是在程序中,双重否定会降低代码的可读性,使程序不易理解,容易产生错觉.人通常是用"正向思维"去理解一件事情的,使用双重否定的判断,需要开发者以"逆向思维"的方式去理解它的含义.另外,在写程序时,"!"符号很容易被疏忽和遗漏,一不小心则会编写出错误的代码,从而产生bug.所以,在程序中,我们应当尽量避免使用双重否定. 优惠券是否未被使用? 还是以在线商城给用户发放优惠券为例,由于优惠券的初始状态是未被