使用多种界面的最佳方式是什么？

Question

我遇到的情况是，我有很多模型类（~1000），它们实现了任意数量的 5 个接口。所以我有一些类实现了一个，而其他类则实现了四到五个。

这意味着我可以对这五个接口进行任意排列。在经典模型中，我必须实现 32-5 = 27 个“元接口”，将接口“加入”到一个包中。通常，这不是问题，因为 IB 通常扩展 IA 等，但就我而言，五个接口是正交/独立的。

在我的框架代码中，我有一些方法需要实现任意数量的这些接口的实例。因此，假设我们有类 X 和接口 IA、IB、IC、ID 和 IE。 X 实现了 IA、ID 和 IE。

情况变得更糟，因为其中一些接口具有 正式类型参数。

我现在有两个选择：

1. 我可以定义一个接口IADE（或者更确切地说IPersistable_MasterSlaveCapable_XmlIdentifierProvider；下划线只是为了您的阅读乐趣）

2. 我可以将泛型类型定义为 这将为我提供一种方便的方法来混合和使用根据需要匹配接口。

3. 我可以使用这样的代码：IA a = ...; ID d = (ID)a; IE e = (IE)e 然后使用具有正确类型的局部变量来调用方法，即使这三个变量都在同一个实例上工作。或者在每个第二个方法调用中使用强制转换。

第一个解决方案意味着我得到了很多名称非常不可读的空接口。

第二种使用一种“临时”打字。 Oracle 的 javac 有时会遇到这些问题，而 Eclipse 却能正确处理。

最后一个解决方案使用强制转换。纳夫说道。

问题：

1. 是否有更好的混合任意数量接口的解决方案？

2. 是否有任何理由避免使用解决方案 #2 提供的临时类型（除了 Oracle 的 javac 中的缺点）？

注意：我知道编写不能用 Oracle 的 javac 编译的代码是有风险的。我们知道我们可以应对这种风险。

[编辑] 我在这里尝试的似乎有些混乱。我的模型实例可以具有以下特征之一：

• 它们可以是“主从能力”（想想克隆）
• 它们可以有 XML 标识符
• 它们可能支持树操作（父/子）
• 它们可能支持修订
• 等。（是的，该模型是甚至比这更复杂）

现在我有了在树上运行的支持代码。树的扩展是带有修订的树。但我也有没有树的修订。

当我在代码中在修订树管理器中添加子级时，我知道每个实例都必须实现 ITtree 和 IRevisionable 但两者没有通用接口，因为这些是完全独立的问题。

但在实现中，我需要调用树的节点上的方法：

public void addChild( T parent, T child ) {
    T newRev = parent.createNewRevision();
    newRev.addChild( foo );
    ... possibly more method calls to other interfaces ...
}

如果 createNewRevision 位于接口 IRevisionable 中，并且 addChild 位于接口 ITree，定义 T 的选项有哪些？

注意：假设我有几个其他接口以类似的方式工作：有很多地方它们是独立的，但有些代码需要看到它们的混合。 IRevisionableTree 不是解决方案，而是另一个问题。

我可以为每个调用转换类型，但这看起来很笨拙。创建接口的所有排列会很无聊，而且似乎没有合理的模式来压缩巨大的接口名称。泛型提供了一个很好的出路：

public
<T extends IRevisionable & ITree>
void addChild( T parent, T child ) { ... }

这并不总是适用于 Oracle 的 javac，但它看起来紧凑且有用。还有其他选项/评论吗？

Answer 1

松散耦合的功能可能会很有趣。 示例。
这是一种完全不同的方法；解耦事物而不是打字。
基本上接口是隐藏的，作为委托字段实现。

IA ia = x.lookupCapability(IA.class);
if (ia != null) {
    ia.a();
}

它适合这里，就像许多接口一样，解耦的愿望也会增加，并且您可以更轻松地组合相互依赖的接口的情况 (if (ia != null && ib != null) ... ）。

Answer 2

如果您有一个方法（半代码），

void doSomething(IA & ID & IE thing);

那么我主要关心的是：不能更好地定制 doSomething 吗？拆分功能可能会更好吗？还是界面本身定制不当？

我已经多次遇到类似的事情，每次都证明最好向后退一步并重新思考逻辑的完整划分 - 不仅由于您提到的内容，还由于其他内容的担忧。

由于您非常抽象地提出了您的问题（即没有合理的例子），我无法告诉您这对于您的情况是否也是可取的。

Answer 3

我会避免所有尝试表示组合的“人工”接口/类型。这只是糟糕的设计...如果再添加 5 个接口会发生什么？组合的数量呈爆炸式增长。

看来您想知道某个实例是否实现了某些接口。合理的选择是：

• 使用 instanceof - 没有什么可耻的，
• 使用反射通过 object.getClass().getInterfaces() 发现接口 - 你也许可以写一些通用的处理内容的代码
• 使用反射通过 object.getClass().getMethods() 发现方法，并仅调用与接口的已知方法列表匹配的方法（这种方法意味着您没有关心它实现了什么 - 听起来很简单因此听起来是个好主意）

您没有向我们提供任何背景信息来说明您想知道的具体原因，因此很难说出“最佳”方法是什么。

编辑

好。自从添加了您的额外信息后，它就开始有意义了。这里最好的方法是使用回调：不要传入父对象，而是传入接受“子对象”的接口。

这是访问者模式的简单版本。您的调用代码知道它正在调用什么以及它如何处理子项，但是导航和/或决定添加子项的代码没有调用者的上下文。

您的代码看起来像这样（警告：可能无法编译；我只是输入了它）：

public interface Parent<T> {
    void accept(T child);
}

// Central code - I assume the parent is passed in somewhere earlier
public void process(Parent<T> parent) {
    // some logic that decides to add a child
    addChild(parent, child);
}

public void addChild(Parent<T> parent, T child ) {
    parent.accept(child);
}

// Calling code
final IRevisionable revisionable = ...;
someServer.process(new Parent<T> {
    void accept(T child) {
        T newRev = revisionable.createNewRevision();
        newRev.addChild(child);
    }
}

您可能必须处理一些事情，但我希望您理解我想说的内容。

Answer 4

实际上解决方案1是一个很好的解决方案，但是您应该找到更好的命名。

实际上，您会将实现 IPersistable_MasterSlaveCapable_XmlIdentifierProvider 接口的类命名为什么？如果遵循良好的命名约定，它应该具有源自模型实体的有意义的名称。您可以为接口指定相同的名称，并以 I 为前缀。

我不认为拥有许多接口是一个缺点，因为这样您就可以编写模拟实现来进行测试。

Answer 5

我的情况恰恰相反：我知道在代码中的某个点，
foo 必须实现 IA、ID 和 IE（否则，它无法得到
远的）。现在我需要调用所有三个接口中的方法。什么类型
foo 应该得到吗？

您是否能够通过传递（例如）三个对象来完全绕过该问题？因此，

doSomethingWithFoo(WhatGoesHere foo);

您可以：

doSomethingWithFoo(IA foo, ID foo, IE foo);

或者，您可以创建一个实现所有接口的代理，但允许您禁用某些接口（即调用“错误”接口会导致 UnsupportedOperationException）。

最后一个疯狂的想法 - 也许可以为适当的接口创建动态代理，将其委托给您的实际对象。