【问题标题】:RTTI vs. additional methodsRTTI 与其他方法
【发布时间】:2010-07-30 13:05:55
【问题描述】:

我的一些课程应该被区别对待。哪种解决方案更好:

  1. 为我的类层次结构引入新接口,并使用 RTTI(运行时标识)检查类是否实现它
  2. 添加一个返回布尔值的方法,该值指示这个类是应该被正常对待还是应该被特殊对待

以下示例说明了上述情况:

1.

interface SpecialTreatment {}

class Base {}    

class Special extends Base implements SpecialTreatment {}

class Normal extends Base {}


Base reference = new Special();
if(reference instanceof SpecialTreatment)
    // do something special
else
    // normal class

2.

interface Treatment {
    boolean special();
}

class Base {}

class Special extends Base implements Treatment {
    boolean special() { return true; }
}

class Normal extends Base implements Treatment {
    boolean special() { return false; }
}

Treatment reference = new Special();
if(reference.special() == true)
    // do something special
else
    // normal class

【问题讨论】:

    标签: design-patterns rtti


    【解决方案1】:

    如果对类进行不同处理的“原因”是设计决定,则通过接口签名将其标记为解决方案 1。

    如果您的应用程序中的某些状态可能会控制这一点,请使用解决方案 2。

    这方面的例子是 java.io.Serializable 接口,它没有用于识别可序列化实现的方法或字段。您在设计时决定对象是否可序列化。

    关于instanceof 性能的注释,在附加评论后。

    您也可以考虑使用 Annotations 作为替代方案...

    -- 发表评论后编辑 ---

    如果你真的不想继续使用 instanceof(非常快)或注释,你可以这样做..

    interface Special {
        bool isSpecial();
    }
    
    abstract class RuntimeSpecial implements Special {
        protected abstract bool _determineSpecial();
    
        public isSpecial() { return _determineSpecial(); }
    
    }
    
    class IsSpecial implements Special {
        public isSpecial() { return true; }
    }
    
    class IsNotSpecial implements Special {
        public isSpecial() { return false; }
    }
    

    现在扩展任何合适的......

    【讨论】:

    • RTTI 的成本是否比通过接口进行的简单后期绑定高得多?
    • Java 和 .NET 中的 RTTI 非常高效。解决方案一减少了由于返回错误的真/假而导致的错误实现。
    • 听说程序员只有在其他解决方案失败时才能使用RTTI,而多态可以更优雅地解决任何问题。还有其他模式可以让我避免 RTTI 吗?
    • 程序员应该检查所有给定语言/平台的可用设施。您需要问自己的问题是:性能是您的问题吗?例如,您会在紧密循环中运行测试条件吗?
    • 我问的问题更多的是关于常见做法,RTTI 是否被其他程序员普遍使用并认为是可接受的解决方案。
    猜你喜欢
    • 1970-01-01
    • 2015-02-04
    • 2014-09-23
    • 1970-01-01
    • 1970-01-01
    • 2014-05-06
    • 2013-02-23
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多