我已经看到了所有Java类是否应该实现接口的几个答案。意见不同，如果我确定只有一个实现，我个人认为编写接口没有好处。
但是，在这种情况下，此特定类是框架的一部分，将由其他人使用。让用户直接使用实现或者我应该为它创建一个接口是否合适？现在我控制用户通过公共/私人访问方法。
String之类的类没有实现接口，我们直接使用它们。另一方面，该代码很老，也许事情从那时起发生了变化，并且为了避免破坏而没有更新。
答案 0 :(得分：1)
如果您控制实例的创建方式，那么您发布的内容无关紧要。如果你不控制实例的创建方式，那么它就很重要了。
客户端无法创建接口，只能创建实现接口的具体对象。
但是，如果实例总是通过您控制的某种机制（工厂，查找，注入等）创建，那么大多数情况下，接口，抽象或具体类之间的区别根本不是问题
如果希望客户端扩展实例，那么这也会产生影响。您可以扩展接口，但不能像扩展普通类那样。机制和分支有点不同。
最后，大多数情况下，具体类可以转换为没有人更聪明的界面，除非他们正在创建自己的实例。
答案 1 :(得分：0)
首先：一般来说，不要对任何事情保持教条是一个好主意。
以这种方式思考：当你在建造房屋时，你不应该决定使用一种钉子 - 你不能用钉子做任何事情，而且它们是专门设计的。不同的尺寸，让您在需要时选择最适合您特定需求和材料的产品。
因此，如何以及何时使用接口完全取决于类的类型，结构和用途。您当然不必每个班级总是使用一个界面 - 尤其是如果您重视SRP并保持您的课程规模小而且仅限于一个职责。但有时您可能希望这样做，有时您甚至会找到在同一个类中实现多个接口的充分理由。
接口的重要之处在于，无论您将要使用多少不同的实现，都可以将它们用于特定实现中的 abstract 。这样做有很多可能的原因，例如：让别人为你处理实例化（例如应用程序服务器;这种方法经常用于框架，顺便说一句），解耦组件以改善依赖关系管理，而不是忘记单元测试（当代码有代码时，模拟对象要容易得多它不是应该根据API实现的次数来决定的，而是选择保持代码结构清晰，松散耦合和可读的最佳方法。
要决定做什么，首先要了解有关您正在建造的房屋的更多信息：查看SOLID principles并尝试应用这些 - 您将更多地了解抽象和界面，以及它们应该用于。他们也不会对所有事情都有答案，但从那时起你就可以开始自己的观察，并可能发明自己的原则，来处理他们没有涵盖的内容。他们绝对是一个开始的好地方。