我们是否应该始终定义接口和抽象类，即使只有 1 个类扩展它们？答案

【问题标题】：should we always define interface and abstract classes, even when there will only be only 1 class extending them?我们是否应该始终定义接口和抽象类，即使只有 1 个类扩展它们？
【发布时间】：2013-07-29 18:52:07
【问题描述】：

自己是否应该始终定义接口和抽象类，即使只有 1 个类扩展它们？我从事一些小型 Java 项目已经有一段时间了。我一直看到他们总是在他们编写的每个其他类中创建抽象类和接口。但在几乎所有其他情况下，接口仅由一个类实现，抽象类也仅由另一个类扩展。这是因为多个类没有扩展或实现的范围。因此，根据我的理解，如果我们知道会有很多其他类会使用它，我们就可以拥有接口和抽象类。在上述情况下，我觉得应该直接编写具体的类。并且将来如果需要自己可以修改这些类并创建接口等并加以利用。不知何故，我 99% 确信我对多态性使用的理解达不到标准。请让我知道这些概念的正确用法。

【问题讨论】：

虽然这是一个很好的问题，但答案取决于具体的上下文，并且可能会引起意见和讨论，这与主题无关。 Software Engineering 可能会更好。
如果有助于保持代码清洁：是的。还有en.wikipedia.org/wiki/Dependency_inversion_principle
你描述的项目听起来像是过度工程的教科书示例。

标签： java inheritance interface abstract conceptual

【解决方案1】：

如果您将使用多个抽象类和接口，则意味着它们。如果你只打算上一门课，你也不需要。

如果以后您需要两个子类，您可以随时将原始类转换为接口。

要记住的一点是，编写接口和抽象类是安全的。如果功能已知并且已经制作了骨架，则更容易测试您的类并且可以防止错误。

【讨论】：

除此之外：接口对于用于测试目的的单个类是完全合理的（想到存储库）。
@JeroenVannevel 有了像 Mockito 这样的现代框架，（谢天谢地）不再需要了。

【解决方案2】：

如果您有几个类似的类来实现/扩展接口和抽象类，那么接口和抽象类就很有意义。如果您目前只有一个子类，但您知道可以在某个时间添加更多子类，它们也很有意义。

但是，如果您确切地知道永远不会有任何其他类似的类，您就不应该使用它们。那只会减慢程序的速度。

【讨论】：

它不会减慢程序的速度，只会让它稍微变大

【解决方案3】：

如果您想向“客户端”提供 API，则接口和单一实现可能有意义。

您要做的是首先设计 API（接口），然后将其提供给您的客户，无需实施。我看到了两个优点：

您的客户可以在他身边工作，了解您 API 中的所有现有方法：您的团队和客户团队之间可以并行工作。
您不必向他提供您想要保密的实施源。可以在运行时在单独的 jar 中提供实现。

另外，如果您正在开发一个想要保留向后兼容性的系统，我建议您尽快引入接口，以免以后卡住。

否则，我建议您仅在需要时才引入接口，并依靠重构工具轻松更改代码。这将使您更容易理解。其他开发者会为此感谢您。

干杯

【讨论】：