相关疑难解决方法(0)

我正在开发一个应用程序,一种设计方法涉及对instanceof操作员的极大使用.虽然我知道OO设计通常会试图避免使用instanceof,但这是一个不同的故事,这个问题纯粹与性能有关.我想知道是否有任何性能影响？是这么快==吗？

例如,我有一个包含10个子类的基类.在一个获取基类的函数中,我会检查该类是否是子类的实例并执行一些例程.

我想解决它的另一种方法是使用"type id"整数原语,并使用位掩码来表示子类的类别,然后只需对子类"type id"进行掩码比较.表示类别的常量掩码.

被instanceof莫名其妙地由JVM优化得比较快？我想坚持使用Java,但应用程序的性能至关重要.如果之前一直走在这条路上的人可以提供一些建议,那将会很酷.我是在挑剔太多还是专注于错误的事情来优化？

在我的一个项目中,我有两个"数据传输对象"RecordType1和RecordType2,它们继承自RecordType的抽象类.

我希望两个RecordType对象在"process"方法中由同一个RecordProcessor类处理.我的第一个想法是创建一个通用的流程方法,该方法委托给两个特定的流程方法,如下所示:

public RecordType process(RecordType record){

    if (record instanceof RecordType1)
        return process((RecordType1) record);
    else if (record instanceof RecordType2)
        return process((RecordType2) record);

    throw new IllegalArgumentException(record);
}

public RecordType1 process(RecordType1 record){
    // Specific processing for Record Type 1
}

public RecordType2 process(RecordType2 record){
    // Specific processing for Record Type 2
}

我读过Scott Meyers在Effective C++中写了以下内容:

"任何时候你发现你自己编写的形式的代码'如果对象是T1类型,那么做一些事情,但如果它是T2类型,那么做一些其他的事情,'打自己."

如果他是对的,显然我应该打自己.我真的没有看到这是多么糟糕的设计(除非当然有人将RecordType子类化并添加到RecordType3而不向处理它的通用"Process"方法添加另一行,从而创建一个NPE),以及我能想到的替代方案涉及将特定处理逻辑首当其冲地放在RecordType类本身中,这对我来说真的没有多大意义,因为理论上我可以对这些记录执行许多不同类型的处理.

有人可以解释为什么这可能被视为糟糕的设计并提供某种替代方案,仍然负责将这些记录处理到"处理"类？

更新:

• 改变return null以throw new IllegalArgumentException(record);
• 简单来说,简单的RecordType.process()方法有三个原因是不够的:首先,处理实际上远离RecordType,在RecordType子类中应该拥有自己的方法.此外,理论上可以由不同的处理器执行大量不同类型的处理.最后,RecordType被设计为一个简单的DTO类,其中定义了最小的状态改变方法.