为了账号安全,请及时绑定邮箱和手机立即绑定

在Java中避免使用instanceof

在Java中避免使用instanceof

梵蒂冈之花 2019-08-26 14:16:30
在Java中避免使用instanceof具有一系列“instanceof”操作被认为是“代码味道”。标准答案是“使用多态”。在这种情况下我该怎么做?基类有许多子类; 没有一个在我的控制之下。类似的情况是Java类Integer,Double,BigDecimal等。if (obj instanceof Integer) {NumberStuff.handle((Integer)obj);}else if (obj instanceof BigDecimal) {BigDecimalStuff.handle((BigDecimal)obj);}else if (obj instanceof Double) {DoubleStuff.handle((Double)obj);}我确实可以控制NumberStuff等等。我不想在几行代码中使用多行代码。(有时我将一个HashMap映射到一个IntegerStuff的实例,将BigDecimal.class映射到一个BigDecimalStuff的实例等等。但是今天我想要一些更简单的东西。)我想要像这样简单的东西:public static handle(Integer num) { ... }public static handle(BigDecimal num) { ... }但是Java不会那样工作。我想在格式化时使用静态方法。我正在格式化的东西是复合的,其中Thing1可以包含一个数组Thing2s和Thing2可以包含一个Thing1s数组。当我实现这样的格式化程序时,我遇到了问题:class Thing1Formatter {  private static Thing2Formatter thing2Formatter = new Thing2Formatter();  public format(Thing thing) {      thing2Formatter.format(thing.innerThing2);  }}class Thing2Formatter {  private static Thing1Formatter thing1Formatter = new Thing1Formatter();  public format(Thing2 thing) {      thing1Formatter.format(thing.innerThing1);  }}是的,我知道HashMap和更多代码也可以修复它。但相比之下,“instanceof”似乎更具可读性和可维护性。有什么简单但不臭吗?注释已添加5/10/2010:事实证明,将来可能会添加新的子类,而我现有的代码必须优雅地处理它们。在这种情况下,类上的HashMap不起作用,因为找不到类。一系列if语句,从最具体的开始到以最一般的结尾,可能是最好的:if (obj instanceof SubClass1) {    // Handle all the methods and properties of SubClass1} else if (obj instanceof SubClass2) {    // Handle all the methods and properties of SubClass2} else if (obj instanceof Interface3) {    // Unknown class but it implements Interface3    // so handle those methods and properties} else if (obj instanceof Interface4) {    // likewise.  May want to also handle case of    // object that implements both interfaces.} else {    // New (unknown) subclass; do what I can with the base class}
查看完整描述

3 回答

?
肥皂起泡泡

TA贡献1829条经验 获得超6个赞

您可能对Steve Yegge的亚马逊博客中的这篇文章感兴趣:“当多态失败时”。基本上他正在解决这样的情况,当多态性导致比它解决的更多麻烦时。

问题是,要使用多态,你必须使“处理”逻辑成为每个“切换”类的一部分 - 即在这种情况下为整数等。显然这不切实际。有时甚至在逻辑上它都不是放置代码的正确位置。他建议将'instanceof'方法视为几种邪恶中较小的一种。

与您被迫编写臭代码的所有情况一样,请将其保持在一个方法(或最多一个类)中,以便气味不会泄漏。


查看完整回答
反对 回复 2019-08-26
?
12345678_0001

TA贡献1802条经验 获得超5个赞

正如评论中所强调的那样,访客模式将是一个不错的选择。但是如果没有对目标/接受者/被访者的直接控制,则无法实现该模式。这里是访问者模式可能仍然可以在这里使用的一种方式,即使你没有使用包装器直接控制子类(以Integer为例):

public class IntegerWrapper {
    private Integer integer;
    public IntegerWrapper(Integer anInteger){
        integer = anInteger;
    }
    //Access the integer directly such as
    public Integer getInteger() { return integer; }
    //or method passthrough...
    public int intValue() { return integer.intValue(); }
    //then implement your visitor:
    public void accept(NumericVisitor visitor) {
        visitor.visit(this);
    }}

当然,包装最终类可能被认为是它自己的气味,但也许它很适合你的子类。就我个人而言,我认为instanceof这里的味道不是很糟糕,特别是如果只限于一种方法,我会很乐意使用它(可能超过我自己的建议)。正如你所说,它具有可读性,类型安全性和可维护性。一如既往,保持简单。


查看完整回答
反对 回复 2019-08-26
  • 3 回答
  • 0 关注
  • 632 浏览

添加回答

举报

0/150
提交
取消
微信客服

购课补贴
联系客服咨询优惠详情

帮助反馈 APP下载

慕课网APP
您的移动学习伙伴

公众号

扫描二维码
关注慕课网微信公众号