java - 在 Java 中，对复杂模型使用接口(interface)是否会提高性能？

Question

标题很难理解，但我不确定如何用另一种方式来总结。欢迎任何编辑澄清。

我被告知并建议使用接口(interface)来提高性能，即使在不特别需要常规“接口(interface)”角色的情况下也是如此。在这种情况下，对象是大模型(在 MVC 意义上)，具有许多方法和字段。

向我推荐的“良好用途”是创建一个接口(interface)，并具有其独特的实现。肯定不会有任何其他类实现此接口(interface)。有人告诉我这样做更好，因为它“减少”(或接近)其他将使用此类方法的类，因为这些对象引用其接口(interface)中的对象(所有公共(public)方法)来自界面中复制的实现)。

这对我来说似乎很奇怪，因为它对我来说似乎是 C++ 的用法(带有头文件)。我明白了这一点，但在 Java 中？

为这种独特的实现制作接口(interface)真的有意义吗？我真的很感激对这个主题的一些澄清，所以我可以证明不遵循这种行为，以及它因复制所有声明而造成的麻烦。

---

编辑:感谢大家的回答，这真的很有帮助和指导(其中大部分，不仅仅是“接受”的)。

在性能上显然没有优势，除了接口(interface)通常的 OO 角色之外，我现在可以从中获得更大范围的兴趣(视情况而定)。

Answer 1

使用接口(interface)与性能没有太大关系(开发团队的性能除外，即开发速度)。它更多的是控制依赖关系，并分离程序的不相关部分。

如果您在代码中直接依赖于具体类 C，那么该代码将更难进行单元测试等。如果您改为依赖于接口(interface)，则可以轻而易举地在单元测试中创建模拟实现。

当然，您可能不需要将您类的所有方法拉入父接口(interface)。事实上，您可能不需要一个单一的父界面。分析该类的使用情况(尤其是像您这样的大类)，您可能会发现两个或更多不同的方法组，由不同的客户端使用(例如，一组客户端仅查询对象状态，而另一组更新它).这使得创建两个或更多不同的界面成为可能，每个界面都更加简单和清晰。

这种分析甚至可能得出这样的结论，即您的类试图做太多事情(而不是拥有一个 single responsibility )，您最好将它的一些内容提取到一个单独的类中!换句话说，一旦您开始考虑界面并针对界面进行编程，您就会开始在不同的层面上看待设计，这可能会带来更好的设计解决方案。

综上所述，如果经过上述所有分析后您仍然没有看到您的模型类的接口(interface)被使用，请记下它。比方说，半年后重新审视它。然后，如果您仍然觉得它没有收回成本，就扔掉它。接口(interface) - 与程序的任何其他元素一样 - 应该始终有明确的目的和存在的理由(并且比“我的同事告诉我创建它”更好)。它们不是 Elixir 。如果你巧妙地使用它们，你可以使你的代码更好。如果你愚蠢地使用它们，你的代码会变得更糟。你在这里发布这个问题意味着你想学习如何巧妙地使用它们，这很好:-)