0

我已经看到了几个关于是否所有 Java 类都应该实现接口的答案。意见不同，如果我确定只有一个实现，我个人看不到编写接口的好处。

然而，在这种情况下，这个特定的类是框架的一部分，将被其他人使用。让用户直接使用实现是否合适，或者我应该为它创建一个接口？现在我正在通过公共/私人控制用户对方法的访问。

诸如此类的类String不实现接口，我们直接使用它们。另一方面，该代码已经很老了，也许从那时起事情已经发生了变化，并且没有更新它以避免破坏某些东西。

4

2 回答 2

1

如果您控制实例的创建方式，那么您发布的内容无关紧要。如果您不控制实例的创建方式，那么这很重要。

客户端不能创建接口，他们只能创建实现它们的具体对象。

但是，如果实例总是通过您控制的某种机制（工厂、查找、注入等）创建，那么大多数情况下，接口、抽象类或具体类之间的区别根本不成问题。

如果期望客户扩展实例，那么这也会产生影响。您可以扩展接口，但不能以扩展普通类的方式。机制和后果有点不同。

最后，大多数时候，一个具体的类可以转换为一个接口，没有人比它更聪明，除非他们创建自己的实例。

于 2013-03-20T00:00:19.367 回答
0

首先：对任何事情不要教条主义通常是个好主意。

可以这样想：当你建造房子时，你不应该决定要使用一种钉子——你不能对所有东西都使用钉子，它们是故意设计成不同尺寸的让您在需要时选择最适合您的特定需求和材料的类型。

因此，如何以及何时使用接口完全取决于类的类型、结构和预期用途。您当然不必总是为每个类使用一个接口——尤其是如果您重视 SRP 并保持您的类很小并且仅限于单一职责时。但有时您可能想要这样做，有时您甚至会找到在同一个类中实现多个接口的充分理由。

关于接口的重要一点是，您可以使用它们从特定实现中抽象出来，而不管您将拥有多少不同的实现。这样做有很多可能的原因，例如让其他人为您处理实例化（例如应用程序服务器；这种方法经常用于框架，顺便说一句），解耦组件以改进依赖管理，不要忘记单元测试（它是模拟对象要容易得多，当您的代码仅引用接口时）等等。这不是应该根据 API 实现的次数来决定的，而是要选择保存代码的最佳方式结构清晰，松耦合且可读。

要决定做什么，首先要更多地了解你正在建造的房子：查看SOLID 原则并尝试很好地应用这些原则 - 你会更多地了解抽象和接口，以及它们应该用于什么。他们也不会对所有事情都有答案，但是从那时起，您可以开始进行自己的观察，并可能发明自己的原则来处理他们未涵盖的内容。他们绝对是一个开始的好地方。

于 2013-03-20T00:23:10.553 回答