简单的共享方法是否需要接口？答案

【问题标题】：Are interfaces necessary for simple shared methods?简单的共享方法是否需要接口？
【发布时间】：2015-06-20 21:32:15
【问题描述】：

仅仅因为一组对象共享几个公共方法而使用接口有什么好处吗？

例如，我有GameObject、GameComponent 和GameLevel。每个都有函数onUpdate() 和onDraw()。

我应该创建一个包含onUpdate() 和onDraw() 的IGameEntity 接口并让每个对象都实现它吗？我不打算存储任何类型的IGameEntity 列表或我只需要访问这两个函数的任何类似情况，那么这种抽象级别是否具有建设性？

【问题讨论】：

我认为 YAGNI 适用于此。如果您确实最终想要使用它，您可以随时定义此接口。
非常正确，对函数声明的改动很小。感谢您的回复！
@aceads0529 接口是类履行的一种契约，因此如果您希望类必须实现某些功能，您应该使用接口来确保这是一种良好的编程习惯
在我看来，当你不需要多态行为时使用接口会阻碍程序的理解。如果我看到一个界面，我希望它会有用处。如果没有，它看起来就像杂乱无章。

标签： oop interface abstraction

【解决方案1】：

您可能不需要费心，因为您可以稍后根据需要对其进行重构。（除非代码是公共 API 的一部分，在这种情况下应考虑其用户。）

接口是对类型的有意义的约束。一般来说，我会说一个名为IGameEntity 的接口听起来有问题。 是什么？从它的功能来看，它还不如称为IUpdatableDrawable，但这个名字已经表明它是一个古怪的东西。有时需要引入这样的概念，但在可读性方面这是一种成本，只有在有充分理由的情况下才能支付。

一个好的界面可以为属于一起的一组功能命名。就像在口语中一样，在没有用例的情况下命名概念毫无意义。

【讨论】：

【解决方案2】：

不，这样做没有任何好处。这是关键声明：

我无意存储任何类型的IGameEntity 列表或我只需要访问这两个函数的任何类似情况。

接口的目的是解耦意图和实现。这允许消费者调用接口方法而不引入对实现的依赖。它还允许在不影响消费者的情况下替换新的实现。

但所有这些优点只有在有人使用该界面时才适用。如果对一组异构实现者没有用处（例如IGameEntity 对象的列表），则该接口不提供任何价值。（事实上，界面的存在可能会让消费者相信他们应该使用IGameEntity对象列表，而没有理由这样做。）

【讨论】：

【解决方案3】：

如果这三个类都需要onUpdate()和onDraw()方法，那么是的，你需要创建接口并实现它。在其他方面，您无法确定所有三个类都有onUpdate() 和onDraw()implementations。并且将接口调用为IGameEntityFunction会更好。

【讨论】：

【解决方案4】：

如果您的类中有这些方法的不同实现，则应使用接口，另一方面，如果您有方法的基本实现，则可以使用抽象类。

【讨论】：