优化java代码的一些小技巧（四）————使用多态

最新推荐文章于 2021-03-01 09:55:57 发布

choujiang1323

最新推荐文章于 2021-03-01 09:55:57 发布

阅读量273

点赞数

CC 4.0 BY-SA版权

文章标签： java

原文链接：https://my.oschina.net/fl128818/blog/1550503

探讨了在编程中使用多态与条件句的优劣，通过实例对比，阐述了多态在代码扩展性和编译时错误检查方面的优势。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

4.使用多态

对于任何一门编程语言来说，条件句都是一种很常见的结构，而且它的存在也是有一定原因的。因为，不同的组合，可以允许用户根据给定值或对象的瞬时状态改变系统的行为。假设用户需要计算各银行账户的余额，如以下的代码:

public enum BankAccountType {  
    CHECKING,  
    SAVINGS,  
    CERTIFICATE_OF_DEPOSIT;  
}  
public class BankAccount {  
    private final BankAccountType type;  
    public BankAccount(BankAccountType type) {  
        this.type = type;  
    }  
    public double getInterestRate() {  
        switch(type) {  
            case CHECKING:  
                return 0.03; // 3%  
            case SAVINGS:  
                return 0.04; // 4%  
            case CERTIFICATE_OF_DEPOSIT:  
                return 0.05; // 5%  
            default:  
                throw new UnsupportedOperationException();  
        }  
    }  
    public boolean supportsDeposits() {  
        switch(type) {  
            case CHECKING:  
                return true;  
            case SAVINGS:  
                return true;  
            case CERTIFICATE_OF_DEPOSIT:  
                return false;  
            default:  
                throw new UnsupportedOperationException();  
        }  
    }  
}

虽然上面这段代码满足了基本的要求，但是有个很明显的缺陷：用户只是根据给定帐户的类型决定系统的行为。这不仅要求用户每次要做决定之前都需要检查账户类型，还需要在做出决定时重复这个逻辑。例如，在上面的设计中，用户必须在两种方法都进行检查才可以。这就可能会出现失控的情况，特别是接收到添加新帐户类型的需求时。

我们可以使用多态来隐式地做出决策，而不是使用账户类型用来区分。为了做到这一点，我们将BankAccount的具体类转换成一个接口，并将决策过程传入一系列具体的类，这些类代表了每种类型的银行帐户：

public interface BankAccount {  
    public double getInterestRate();  
    public boolean supportsDeposits();  
}  
public class CheckingAccount implements BankAccount {  
    @Override  
    public double getIntestRate() {  
        return 0.03;  
    }  
    @Override  
    public boolean supportsDeposits() {  
        return true;  
    }  
}  
public class SavingsAccount implements BankAccount {  
    @Override  
    public double getIntestRate() {  
        return 0.04;  
    }  
    @Override  
    public boolean supportsDeposits() {  
        return true;  
    }  
}  
public class CertificateOfDepositAccount implements BankAccount {  
    @Override  
    public double getIntestRate() {  
        return 0.05;  
    }  
    @Override  
    public boolean supportsDeposits() {  
        return false;  
    }  
}

这不仅将每个帐户特有的信息封装到了到自己的类中，而且还支持用户可以在两种重要的方式中对设计进行变化。

首先，如果想要添加一个新的银行帐户类型，只需创建一个新的具体类，实现了BankAccount的接口，给出两个方法的具体实现就可以了。在条件结构设计中，我们必须在枚举中添加一个新值，在两个方法中添加新的case语句，并在每个case语句下插入新帐户的逻辑。

其次，如果我们希望在BankAccount接口中添加一个新方法，我们只需在每个具体类中添加新方法。在条件设计中，我们必须复制现有的switch语句并将其添加到我们的新方法中。此外，我们还必须在每个case语句中添加每个帐户类型的逻辑。

在数学上，当我们创建一个新方法或添加一个新类型时，我们必须在多态和条件设计中做出相同数量的逻辑更改。

例如，如果我们在多态设计中添加一个新方法，我们必须将新方法添加到所有n个银行帐户的具体类中，而在条件设计中，我们必须在我们的新方法中添加n个新的case语句。如果我们在多态设计中添加一个新的account类型，我们必须在BankAccount接口中实现所有的m数，而在条件设计中，我们必须向每个m现有方法添加一个新的case语句。

虽然我们必须做的改变的数量是相等的，但变化的性质却是完全不同的。

在多态设计中，如果我们添加一个新的帐户类型并且忘记包含一个方法，编译器会抛出一个错误，因为我们没有在我们的BankAccount接口中实现所有的方法。

在条件设计中，没有这样的检查，以确保每个类型都有一个case语句。

如果添加了新类型，我们可以简单地忘记更新每个switch语句。这个问题越严重，我们就越重复我们的switch语句。我们是人类，我们倾向于犯错误。因此，任何时候，只要我们可以依赖编译器来提醒我们错误，我们就应该这么做。

关于这两种设计的第二个重要注意事项是它们在外部是等同的。例如，如果我们想要检查一个帐户的利率，条件设计就会类似如下:

BankAccount checkingAccount = new BankAccount(BankAccountType.CHECKING);  
System.out.println(checkingAccount.getInterestRate()); // Output: 0.03

多态设计将类似如下:

BankAccount checkingAccount = new CheckingAccount();  
System.out.println(checkingAccount.getInterestRate()); // Output: 0.03

从外部的角度来看，我们都是在BankAccount对象上调用getXXX()。

如果我们将创建过程抽象为一个工厂类的话，这种外部调用的等同性将更加明显：

public class ConditionalAccountFactory {  
    public static BankAccount createCheckingAccount() {  
         return new BankAccount(BankAccountType.CHECKING);  
    }  
}  
public class PolymorphicAccountFactory {  
    public static BankAccount createCheckingAccount() {  
         return new CheckingAccount();  
    }  
}  
// In both cases, we create the accounts using a factory  
BankAccount conditionalCheckingAccount = ConditionalAccountFactory.createCheckingAccount();  
BankAccount polymorphicCheckingAccount = PolymorphicAccountFactory.createCheckingAccount();  
// In both cases, the call to obtain the interest rate is the same  
System.out.println(conditionalCheckingAccount.getInterestRate()); // Output: 0.03  
System.out.println(polymorphicCheckingAccount.getInterestRate()); // Output: 0.03

将条件逻辑替换成多态类是非常常见的，因此已经发布了将条件语句重构为多态类的方法。此外，马丁·福勒(Martin Fowler)的《重构》(p . 255)也描述了执行这个重构的详细过程。

就像本文中的其他技术一样，对于何时执行从条件逻辑转换到多态类，没有硬性规定。

在测试驱动的设计中：例如，Kent Beck设计了一个简单的货币系统，目的是使用多态类，但发现这使设计过于复杂，于是便将他的设计重新设计成一个非多态风格。

经验和合理的判断将决定何时是将条件代码转换为多态代码的合适时间。

结束语
作为程序员，尽管平常所使用的常规技术可以解决大部分的问题，但有时我们应该打破这种常规，主动寻求一些创新。毕竟作为一名开发人员，扩展自己知识面的的广度和深度，不仅能让我们做出更明智的决定，也能让我们变得越来越聪明。

转载于:https://my.oschina.net/fl128818/blog/1550503