如果只有一个类实现接口，那么它还有意义吗？
看看我新工作的（成熟）代码库，有一个接口，并且只有一个类实现它（据我所知）。我可以/应该摆脱这个界面吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
看看我新工作的（成熟）代码库，有一个接口，并且只有一个类实现它（据我所知）。我可以/应该摆脱这个界面吗？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（9）
决不！它的有害影响为零，有一天有人可以交换实现而无需重构大量代码。
No way! Its has zero harmful effects and one day somebody can swap an implementation without having to refactor tons of code.
除了已经提供的好的答案之外 - 如果在将来的某个时候需要模拟一个类以进行测试，那么当已经有一个可用的接口时，这样做会容易得多！
In addition to the good answers already provided - if at some point in the future that one class needs to be mocked for testing purposes, it's a lot easier to do so when there's already an interface available!
今天，没有。六个月后，项目的复杂性将增加十倍？谁知道呢。就您而言，如果这是遗留代码，那么实现一次的接口就没有什么价值，而且也没有必要进行删除它所涉及的重构。 “如果它有效，就不要修复它”。
Today, no. Six months from now after the project has grown tenfold in complexity? Who knows. To your point, if this is legacy code, there is little value to an interface that is implemented once, but there is also no point to going through the refactoring involved in removing it. "If it works, don't fix it".
既然你提到了成熟的基础，我想提一下另一个现实世界的例子：Hibernate的Session。
Session 是一个仅由一个类实现的接口： SessionImpl。但是，如果您过去使用过 hibernate，或者阅读过其源代码，您可能已经注意到到处都使用 Session，而不是 SessionImpl。
这是错误的设计吗？绝对不是。它被称为“替代原则”或“面向接口的编程”。这意味着通过使用接口而不是实现，您可以毫不费力地扩展代码，只需相应地实例化新类，但始终使用接口。如果没有人创建一个实现Session的新类，还会出错吗？不，还是没有错。
我的两分钱。
Since you mention a mature base, I'd like to mention another real world example: Hibernate's Session.
Session is an interface implemented only by one class: SessionImpl. However, if you've used hibernate in the past, or read its source code, you probably have noticed how Session is used everywhere, instead of SessionImpl.
Is this wrong design? Definetly no. Its called 'The substitution principle', or 'programming towards interfaces'. It means that by using the interface instead of the implementation, you can extend your code without any effort, just instantiating your new classes accordingly, but always using the interface. Will it still be wrong if no one creates a new class implementing Session? No, still not wrong.
My two cents.
除了其他答案中给出的原因之外，仅实现一个接口就可以通过构建代理来拦截方法，而无需使用仪器。它用于日志记录、封装事务中的操作等。它被多个框架使用。
Apart from the reasons given in the other answers, only implementing an interface allows intercepting methods by building proxies without using instrumentation. This is used for logging, encapsulating operations in a transaction, etc. It is used by several frameworks.
我想说这取决于情况，但在大多数情况下，对于某些类来说，接口是一个好主意。使用接口使模拟变得更容易，当您使用 IoC 容器时，接口开始变得很有意义，特别是当您开始实现跨容器共享的服务时。然后，您将能够将服务的实现与需要该服务的类解耦。
I would say it depends, but in most cases an interface is a good idea on certain classes. Mocking is made easier using interfaces and when you use an IoC container, then interfaces start making a lot of sense, especially when you start implementing services shared across the container. You will then be able to decouple the implementation of the service from the class needing the service.
是的，接口是有道理的，因为可以想象，将来可能会有不止一种实现。当然，您可以在这里做得太过火，为所有东西创建接口，这样就可以找到平衡点。
Yes, there is a point to interfaces, as there could conceivably be more than one implementation in the future. You can of course go overboard here and create interfaces for everything, so there is a balance to be found.
我发现，当您知道接口永远不会由除该类之外的任何其他对象实现时，包含该接口只是令人烦恼。通常，我设置代码编辑器，以便我按功能键导航到函数的定义。当存在接口时，我最终会看到接口定义而不是实现。然后我必须去寻找实际的实现。这花费了我的时间，足以弥补删除和重新实现该接口所花费的时间。我偶尔会删除这样的接口，并且我从未发现需要重新实现我决定删除的接口。在单元测试方面，现代模拟系统已经完全消除了对该接口的需求。
I find the inclusion of an interface when you know it's never going to be implemented by anything other than that one class is just annoying. Typically, I have my code editor set up such that I hit a function key to navigate to the definition of the function. When an interface is present, I end up in the interface definition instead of the implementation. Then I have to go find the actual implementation. The amount of time this has cost me has more than made up for the time spent in removing and re-implementing that interface. I have occasionally removed such an interface, and I've never found a need to re-implement one I decided to remove. In terms of unit testing, modern mocking systems have completely removed the need for having that interface.
即使人们不太同意每 1000 行代码的错误数量，这两者似乎是相关的（https://stackoverflow.com/questions/862277/what-is-the-industry-standard-for-bugs-per-1000-lines-of-代码）。更少的行数==更少的错误。
此外，更改接口名称的实现名称应该就是这里要做的全部事情。
如果重构工作量很小并且减少了代码，那么我宁愿抑制接口。
Even if people don't quite agree on the number of bug per 1000 lines of code, those two seem correlated (https://stackoverflow.com/questions/862277/what-is-the-industry-standard-for-bugs-per-1000-lines-of-code). Less lines == less bugs.
Also, changing the name of the implementation for the name of the interface should be all there is to do here.
If the refactoring effort is minimal and it reduces the code, I'll be rather for the supression of the interface.