使用界面有什么好处只是因为一组对象共享几个公共方法？
例如，我有GameObject，GameComponent和GameLevel。每个都有函数onUpdate()和onDraw()。
我应该创建一个包含IGameEntity和onUpdate()的{{1}}接口，并让每个对象实现它吗？我没有意图存储任何类型的onDraw()列表或任何类似的情况，我只需要访问这两个函数，这个抽象层次是否具有建设性？
答案 0 :(得分：0)
不，这样做没有任何好处。以下是关键声明：
我无意存储任何类型的
IGameEntity列表或任何类似的情况，我只需要访问这两个函数。
接口的目的是解耦 intent 和实现。这允许使用者调用接口方法而不引入对实现的依赖。它还允许替换新的实现而不影响消费者。
但是，如果有人使用界面，所有这些优势仅适用于。如果一组异构实现者没有有用的情况（例如IGameEntity个对象的列表），那么该接口不提供任何值。 （事实上，界面的存在可能会导致消费者相信他们应该使用IGameEntity对象列表时没有理由这样做。）
答案 1 :(得分：0)
您可能不需要打扰，因为如果需要，您可以稍后重构它。 （除非代码是公共API的一部分，否则应考虑其用户。）
接口是对类型的有意义约束。一般来说，我说一个名为IGameEntity的界面听起来有问题。什么是 它？从它的功能来看，它可能也被称为IUpdatableDrawable，但是这个名字已经表明它将是一个古怪的东西。有时候有必要引入这样的概念，但这只是在可读性方面的成本，只应该有充分理由支付。
良好的界面为一组属于一起的功能提供名称。就像在口语中一样，在没有用例的情况下命名概念也没什么意义。
答案 2 :(得分：-1)
如果你在这些方法的类中有不同的实现，你应该使用接口，另一方面，如果你有方法的基本实现，你可以使用抽象类。
答案 3 :(得分：-1)
如果这三个类需要onUpdate()和onDraw()方法，那么是的，您需要创建接口并实现它。换句话说，您无法确定所有三个类都有onUpdate()和onDraw()实现。
最好将接口称为IGameEntityFunction。