Question

如果我有接口：

public interface ANewThing { IKey Key { get; } }

public interface AnOldThing { object Key{ get; } }

public interface ACompositeThing : ANewThing , AnOldThing  { }

我写这个：

ACompositeThing compositeThing = GetCompositeThing();  
Trace.WriteLine(compositeThing.Key);

它没有编译，抱怨对Key的调用不明确（如果Key属性返回的类型相同则没有任何区别）。我知道在实现ACompositeThing的类中，我可以显式地实现接口ANewThing和AnOldThing，但是当我有不了解具体的方法时，这对我没有帮助实现，只知道他们将被赋予ACompositeThing。

所以我的问题是：

我可以在ACompositeThing界面中执行任何操作来说明如何解决Key属性歧义吗？

就像说'通过此接口访问Key属性时，始终从Key实现中返回ANewThing属性？

或者我是否必须接受我不能这样做，并且在我进行访问之前必须始终将ACompositeThing转发到其他接口之一？

Answer 1

这很讨厌，但你可以在ACompositeThing声明另一个成员：

public interface ACompositeThing : ANewThing , AnOldThing {
    new IKey Key { get; }
}

现在，从来电者的角度来看，这将是首选。但是，这意味着现在可能存在三个不同的实现 - 并且使用ACompositeThing的显式接口实现的任何ANewThing.Key实现 都必须更改公开公开成员，或添加新成员以实施ACompositeThing.Key。

当然，如果可能可以，你应该避免这种情况 - 或者只在非常有限的时间内从旧界面转换到新界面。

Answer 2

更多的解决方法而不是答案：使ACompositeThing成为显式实现Key属性的基类（而不是接口）。

Answer 3

我可以在ACompositeThing界面中做任何事情来说明如何解决Key属性歧义吗？

喜欢说＆＃39;当通过此接口访问Key属性时，始终从ANewThing实现中返回Key属性＆＃39;？

试试这段代码：

ANewThing newThing = GetCompositeThing();  
Trace.WriteLine(newThing.Key);

或

ACompositeThing compositeThing = GetCompositeThing();  
Trace.WriteLine(((ANewThing)compositeThing).Key);

Answer 4

这是一个典型的问题，称为“钻石问题”或“钻石继承”。在大多数情况下，它源于糟糕的OOP设计或错误的命名约定。我认为这也是你的问题。

尝试谷歌“钻石问题”一点，有各种解决方案。

解决接口中的歧义，该接口扩展了具有相同名称的方法的两个其他接口

4 个答案: