接口是否与多态兼容

Question

我在与多态类型（甚至多态接口）交互的接口概念上遇到了麻烦。我正在使用 C# 进行开发，并希望得到与此定义保持接近的答案，尽管我认为这仍然为每个人提供了足够的空间来提出答案。

举个例子，假设您想编写一个程序来绘制事物。您为绘制的actor定义一个界面，并为绘制的主题定义一个界面，此外，您还有一些可以以更具体的方式绘制的主题。

interface IPainter {
  void paint(IPaintable paintable);
}
interface IPaintable {
  void ApplyBaseLayer(Color c);
}
interface IDecalPaintable : IPaintable {
  void ApplyDecal(HatchBrush b);
}

我可以想象制作一个类似于以下内容的画家：

class AwesomeDecalPainter : IPainter
  {
    public void paint(IPaintable paintable) {
      IDecalPaintable decalPaintable = (IDecalPaintable)paintable;
      decalPaintable.ApplyBaseLayer(Color.Red);
      decalPaintable.ApplyDecal(new HatchBrush(HatchStyle.Plaid, Color.Green));
    }
  }

当然，如果paintable 没有实现IDecalPaintable，这将抛出。它立即引入了 IPainter 实现和它所操作的 IPaintable 之间的耦合。但是，我也认为说 AwesomeDecalPainter 不是 IPainter 只是因为它的使用仅限于 IPaintable 域的子集是没有意义的。

所以我的问题实际上有四个方面：

• 接口是否兼容 多态性？
• 好不好 设计实现一个IPainter 可以在 IDecalPaintable 上操作吗？
• 如果可以独占怎么办 在 IDecalPaintable 上？
• 是否有任何文献或源代码 举例说明接口和多态类型如何 应该互动吗？

Answer 1

类的接口是该类“用户”的工具。接口是类的公开表示，它应该向任何考虑使用它的人宣传哪些方法和常量可以从外部访问和访问。因此，顾名思义，它始终位于用户和实现它的类之间。

另一方面，抽象类是一种工具，旨在帮助扩展它的类的“实现者”。它是一种基础设施，可以对具体类的外观施加限制和指导。从类设计的角度来看，抽象类在架构上比接口更重要。在这种情况下，实现者位于抽象类和具体类之间，将后者构建在前者之上。

所以简单地回答你的问题，接口是代码要尊重的“合同”。当以这种方式使用时，它更适用于多态性的继承。

抽象类，它们定义了一个“类型”。当具体的子类使用抽象类并重新定义方法、添加新方法等时……你会看到多态性在起作用。

我知道这篇文章可能会让您更加困惑，直到我学会了设计模式，这对我来说才有意义。通过掌握一些简单的模式，您将更好地了解每个对象的作用以及继承、多态性和封装如何协同工作以构建设计简洁的应用程序。

祝你好运

Answer 2

接口不仅与多态兼容——它们对它来说是必不可少的。您似乎缺少的部分想法是，如果有一个像 IPaintable 这样的接口，则期望实现它的每个对象都将提供一些默认的绘制方法，通常封装其他方法，这些方法将以某种有用的方式配置对象.

例如，IPaintable 接口可能会定义一个绘制方法：

无效油漆（ICanvas 画布）；

请注意，Paint 方法没有说明应该绘制什么、什么颜色或其他任何内容。各种可绘制对象会暴露属性来控制这些东西。例如，Polygon 方法可能会处理 OutlineColor 和 FillColor 属性以及 SetVertices() 方法。想要绘制大量对象的例程可以接受 IEnumerable(Of IPaintable) 并简单地对所有对象调用 Paint，而不必知道如何绘制它们。一个对象是通过调用 Paint 来绘制的，除了应该在其上绘制它的画布之外没有任何参数，这一事实绝不会阻止 Paint 方法执行各种精美的渐变填充、纹理映射、光线跟踪或其他图形效果。控制绘画的代码对这些事情一无所知，但 IPaintable 对象本身会保存他们需要的所有信息，因此不需要调用代码来提供它。

Answer 3

问题实际上是您定义了一个模糊的接口，合同是一个更合适的术语。就像你进了麦当劳然后点了一个汉堡：

interface Resturant
{
    Burger BuyBurger();
}

接你订单的人一会看起来有点困惑，但最终他/她会为你提供任何汉堡，因为你没有指定你想要什么。

这里也一样。你真的只是想定义某些东西是可绘制的吗？如果你问我，这就像自找麻烦。始终尝试使接口尽可能具体。拥有几个小的特定接口总是比一个大的通用接口好。

但是让我们回到你的例子。在您的情况下，所有类只需要能够绘制一些东西。因此我会添加另一个更具体的接口：

    interface IPainter
    {
        void Paint(IPaintable paintable);
    }
    interface IDecalPainter : IPainter
    {
        void Paint(IDecalPaintable paintable);
    }
    interface IPaintable
    {
        void ApplyBaseLayer(Color c);
    }
    interface IDecalPaintable : IPaintable
    {
        void ApplyDecal(HatchBrush b);
    }

    class AwesomeDecalPainter : IDecalPainter
    {
        public void Paint(IPaintable paintable)
        {
            IDecalPaintable decalPaintable = paintable as IDecalPaintable;
            if (decalPaintable != null)
                Paint(decalPaintable);
            else
                paintable.ApplyBaseLayer(Color.Red);
        }

        public void Paint(IDecalPaintable paintable)
        {
            paintable.ApplyBaseLayer(Color.Red);
            paintable.ApplyDecal(new HatchBrush(HatchStyle.Plaid, Color.Green));
        }
    }

我建议您阅读 SOLID 原则。

更新

更完善的接口实现

    interface IPaintingContext
    {
        //Should not be object. But my System.Drawing knowledge is limited
        object DrawingSurface { get; set; }
    }
    interface IPaintable
    {
        void Draw(IPaintingContext context);
    }

    class AwesomeDecal : IPaintable
    {
        public void Draw(IPaintingContext paintable)
        {
            // draw decal
        }
    }

    class ComplexPaintableObject : IPaintable
    {
        public ComplexPaintableObject(IEnumerable<IPaintable> paintable)
        {
            // add background, border 
        }
    }

在这里您可以创建尽可能复杂的绘画项目。他们现在知道他们在什么上绘画，或者在同一表面上使用了哪些其他可绘画材料。

Answer 4

我是否正确理解了您的问题？

我认为你的问题是接口是否可以行使继承的要领？

（即从父接口继承的子接口）。

1) 如果是这样，语法上肯定，为什么不呢？

2) 至于实用性，它可能没有什么价值，因为您的子界面本质上并没有重用您父界面中的任何东西。