【问题标题】:How to properly declare an interface method possibly unsupported by some implementations?如何正确声明某些实现可能不支持的接口方法?
【发布时间】:2017-02-16 10:58:48
【问题描述】:

这是我问的another question的逻辑发展。

假设你有一个接口,其中一些方法可能被具体实现支持或不支持。目标是为客户提供一种合理的方式来确定他的特定实现是否支持每个特定方法,如果不支持则恢复。

我提出的解决方案使用了标准java.lang.UnsupportedOperationException,如果该方法不受支持,则由具体实现抛出:

public interface CommonInterface {
    void possiblyUnsupportedOperation () throws java.lang.UnsupportedOperationException;
}

然而,这被认为是一个糟糕的解决方案,因为不应将异常机制用作检查操作是否可用的手段。所以替代建议是使用测试方法:

public interface CommonInterface {
    void possiblyUnsupportedOperation ();
    boolean isOperationSupported ();
}

但是如果界面有大量的可选操作呢?我应该使用多个测试仪功能吗?我应该创建一个单独的 Enum 来将可选方法映射到并将其作为方法描述符传递给单个测试器函数吗?这两种变体在我看来都有些笨拙。

是否有另一种方式,既是优雅的代码又是良好的设计解决方案?

【问题讨论】:

  • @FedericoPeraltaSchaffner 以便我正确理解您。通过建议使用该原则,您的意思是创建一个包含所有支持的方法的基本接口,然后为每个可选方法创建一个单独的接口,并执行类似if (baseObject instanceof OptionalInterface1) { OptionalInterface1 oi1Object = (OptionalInterface1)baseObject; } 之类的操作吗?
  • @Semisonic 我的意思是你的设计可能存在一些缺陷。在我看来,您的CommonInterface 接口有太多方法。相反,我会有更小的接口(所谓的角色接口)。然后,一个类应该只实现它需要的接口,并且不需要强制转换。 (顺便说一句,如果你需要太多使用instanceof,那就是代码味道,IMO)。
  • @FedericoPeraltaSchaffner 好吧,就我而言,我正在尝试围绕一系列类似服务构建一个包装 API,但是这些服务可能具有与特定服务相关的自定义函数。这些功能具有辅助性质,因此可以避免使用,但是如果它们存在,那么我仍然希望将它们公开给客户端。这就是为什么有大量可选方法的原因——它们不属于任何隔离的角色,而是相同角色的扩展,每个服务对它的看法略有不同。如果重要的话,我最初的问题可能是上下文的来源;)。

标签: java interface api-design


【解决方案1】:

如果您拥有该接口,您可以提取一个Parent 接口,其中包含始终要实现并从该接口继承的方法。

public interface ParentCommonInterface {
    void method1();
    void method2();
}

public interface CommonInterface extends ParentCommonInterface {
    void possiblyUnsupportedOperation();
}

class MyClass implements ParentCommonInterface {...}

如果您不拥有该接口,您可以创建一个Adapter 类并使用该类来声明对象。

public interface CommonInterface {

    void possiblyUnsupportedOperation();
        boolean isOperationSupported();
    }

    public class AdapterClassOne implements CommonInterface {
        void possiblyUnsupportedOperation() {...}
        boolean isOperationSupported() {return false;}
    }
}

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-12-13
    • 2012-09-01
    • 2015-10-23
    • 1970-01-01
    • 2013-09-23
    • 2016-07-03
    • 2014-05-09
    相关资源
    最近更新 更多