在Java中，使用复杂模型的接口是否有性能提升？

Question

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

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

向我推荐的“好用”是创建一个具有独特实现的界面。当然，没有任何其他类实现此接口。我被告知这样做会更好，因为它“暴露更少”（或接近）将使用此类中的方法的其他类，因为这些对象是从其接口引用的对象（所有公共方法）从在界面中重现的实现。）

这对我来说似乎很奇怪，因为它看起来像是一个C ++使用（带有头文件）。在那里，我看到了重点，但在Java？

为这种独特的实现制作界面真的有意义吗？我真的很感激对这个主题的一些澄清，所以我可以证明不遵循这种行为，以及它通过复制所有声明而产生的麻烦。

---

编辑：感谢大家的答案，这真的很有帮助，也很有启发性（大多数人，不仅仅是“接受”的人）。

显然没有性能上的优势，除了界面的通常OO角色外，我现在可以从中获得更大的兴趣范围（取决于具体情况）。

Answer 1

使用接口与性能无关（除了开发团队的性能，即开发速度）。它更多的是控制依赖关系，并分离程序的不相关部分。

如果您直接依赖于代码中的具体C类，则该代码更难以进行单元测试。如果您依赖于接口，则可以在单元测试中创建模拟实现。

当然，您可能不需要将类的所有方法提取到父接口中。实际上，您可能不需要一个单一父接口。分析该类的用法（特别是对于像你这样的大类）的机会是，你找到两个甚至更多不同的方法组，由不同的客户端使用（例如，一组客户端只查询对象状态，而另一组更新它）。这样就可以创建两个或更多不同的接口，每个接口都更简单，更清晰。

这种分析甚至可能导致你的班级试图做太多事情（而不是single responsibility）的结论，你最好把它的一些内容提取到一个单独的类中！换句话说，一旦你开始考虑 - 并编程到 - 接口，你就会开始在不同的层面上看到设计，这可能会带来更好的设计解决方案。

所有这些都说明了，如果经过上述所有分析后仍然没有看到模型类的界面，请记下它。再说一遍，比如半年。然后，如果您仍然认为它没有为自己付费，只需将其转储。接口 - 就像程序的任何其他元素一样 - 应该始终有明确的目的和存在的理由（并且比“我的同事告诉我创建它”更好）。他们不是灵丹妙药。如果你巧妙地使用它们，你可以使代码更好。如果你愚蠢地使用它们，你会使你的代码变得更糟。您在此处发布此问题的事实意味着您想要学习如何巧妙地使用它们，这很好： - ）

Answer 2

首先，接口没有任何性能优势。如果有的话，使用多态代码和动态调度（如C ++虚函数）会带来成本。

认为接口不是增加表现力的东西，而是限制你更好地写作的东西。接口很重要，恕我直言，原因有三：

1）他们可以帮助您编写具有更好封装，数据隐藏，稳定性等的代码。

2）他们可以通过考虑您尝试表示的内容而不是如何实现它来帮助您分离行为和实现。无法添加状态可以防止您意外添加状态。

3）他们允许您将来扩展内容并将您的代码分成独立的单元。每个组件只知道其他服务需要了解的内容。

您可以使用没有状态的抽象类来完成其中一些操作，但接口专门用于此并且具有多个子类型的优点。在C ++中，这种抽象类通常用于模仿接口。

现在，如果你可以直接用类编写一个具有完美封装水平的庞大系统，那就太棒了。但是对于课程来说，往往会有过早地引入状态并建立联系的诱惑。

你应该总是写接口吗？当然不是。总是害怕“永远”规则:)它总是在浪费的工作与无用的复杂性和好处之间取得平衡。凭借时间和经验，您可以获得直觉。

此外，头文件本质上是接口文件。它们通常定义允许的行为，但没有状态。如果您学习C然后学习Java（有些学校会这样做），您将学习C中的ADT，然后了解使用接口的Java中的ADT。

Answer 3

简要 -

1. 您正在接口对象中明确记录该模块的API。您的用户会更清楚，也许会让您考虑该界面中的内容
2. 您可以在同一个对象上提供多个接口，并限制消费者可以做的事情（例如，只读和读写）
3. 模拟框架使用接口，而模拟类是一种非常强大的测试技术

Answer 4

事实上，使用接口而不是类允许您做三件事：

1. 将合同从其实施中删除：合同是接口（这是你宣布要做的），而且这个类显然是实现
2. 提供易于实施的替代方案。这种情况的典型示例意味着在不修改用户代码的情况下将存储机制替换为另一个存储机制（例如，通过Project Voldemort重新调整MySQL）
3. 作为2的好处（这次可以轻松扩展到模型元素），接口允许您进行白盒测试：通过使用模拟框架（JMock，EasyMock，...），您将重新实现接口的实现，这种行为可能是可疑的，通过所谓的“模拟”返回您对测试的期望。这将使您的测试不仅可以检查一个组件，还可以确保错误来自该组件，而不是来自其内部承包商（您给他的界面）。

Answer 5

使用界面的这个原因对我来说也很奇怪。我不知道如何有任何性能优势，如果有的话可能完全不重要。

尽管如此，即使目前有一个实现，也有一些理由使用接口。稍后扩展或提供替代实现可能更容易。 （虽然在任何体面的IDE中都有一个提取接口重构。）测试可能要容易得多：如果你想测试一个只通过接口使用其他类的类，你可以很容易地为其他类提供模拟对象。 p>

Answer 6

以下是2个链接，解释了您为什么要这样做：

http://www.artima.com/lejava/articles/designprinciples.html http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html

它与执行性能无关（更多与程序员（你）的性能有关），因为你从一个实现中减少了一个类的用户 - 除了其他方面，为了简化可测试性和可维护性。

  

肯定没有任何其他类实现此接口。

也许不是今年，但明年可能会有。

Answer 7

接口在Java中被过度使用，部分原因在于语言设计，部分原因是人们认为制作大量接口是很好的设计。

如果Java允许多重继承，抽象类将优于接口。 Scala是一种新的JVM编程语言，它具有Traits的概念，它本质上是具有MI功能的抽象类。

抽象类的优点是，您可以向抽象类添加行为，而不会破坏扩展它的现有类。因此，抽象类作为扩展机制（插件）然后接口也更好。

不幸的是，JMock及其兄弟们鼓励使用大量的BDD测试接口，但这并不一定正确，因为至少有几个库可以模拟具体的对象。

Answer 8

This question targeted C#，但我认为它也适用。最高投票的答案说，为每个类 定义一个接口只是代码噪声 。

Answer 9

有一个相对常见的开发教条，应该有几乎所有东西的接口。据我所知，这是基于关于“程序到接口而不是实现”的货物崇拜心态（这绝对不需要你用遍布接口的代码乱丢），或者使用不能模拟具体类的旧模拟框架进行测试驱动开发。

无视这种废话。

Answer 10

另一种滥用接口的方法？

使用接口没有明显的性能提升。 相反，由于RTTI（基于编译器的功能），可能会对性能产生负面影响