"Duck-type-y“接口/实现

Question

我不知道这个模式的“正确”名称，所以我想用一个简单的例子来描述它。

在C#中，System.Windows.Window包含一个ShowDialog方法。我可以定义一个包含这个方法的接口(加上其他一些功能)。当我创建一个新的Window类时，它将继承Window，并且我可以添加我的接口。现在，我根本不需要关心ShowDialog方法：“神奇地”使用了Window方法，尽管Window不知道我的接口。

一个简单的示例代码：

public interface IMyWindow
{
    bool? ShowDialog();
    // some additional other methods/properties
}

public class MyWindow : Window, IMyWindow
{
    // ShowDialog is "magically" implemented by Window
    #region additional other methods/properties
    #endregion
}

public class MyClass
{
    public void DoSomething()
    {
        IWindow w = new MyWindow();
        bool? result = w.ShowDialog();
    }
}

这种模式是怎么回事？它的使用有多普遍？或者仅仅是.Net其他功能的一些副作用，实际上并没有刻意设计的？其他面向对象的语言如何处理这个问题呢？

编辑：

很久以前，我就提出了一个问题https://stackoverflow.com/questions/23242308/combined-type-generics-something-else --我现在使用基于上述方法的方法。

Answer 1

这是类适配器模式的一个实例，在这个实例中，您使用多个继承从基类继承，以及从要调整基类的接口继承。您不必显式地实现接口函数，这只是接口在C#中工作方式的一个副作用。

Answer 2

我不认为这有名字。

C#接口实现基于可用的方法。基本方法是可用的。虽然这与C++不同，其中一个基本的方法不会覆盖另一个抽象方法，但C++没有指定的接口。Java的工作方式与C#相同。

除非您能够找到一种具有指定接口并与C#和Java不同行为的语言，否则没有必要命名此特性；它只是接口的工作方式。

如果您真的想要调用它，可以将它称为显式接口方法绑定与隐式接口方法绑定。请注意，C#具有“显式接口实现”功能。

Answer 3

我不知道这个建筑有什么意义。实现接口所做的一切就是保证该类中存在某个签名--不管类是定义方法本身还是继承它。

现在，MyWindow已经保证了该方法的存在，因为它扩展了Window，因此通过IMyWindow做出的附加承诺什么也不做。只有当您希望在不需要了解Window对象、只了解IMyWindow的上下文中使用此类对象时，这才有意义。这可以被称为界面隔离的一种形式。

但这有可能吗？即使您不想处理Window API的所有复杂性，您是否也想在不最终使用系统Window类的情况下显示对话框呢？您是否计划通过完全不同的渠道显示对话框的其他类？