Java接口 - 合同到底是什么？

Question

我知道并理解Java中接口的价值.您编写接口,然后您可以更改您的实现,而无需使用该接口更改任何代码.通常,术语"合同"与接口一起使用.我理解它的方式是接口定义应用程序和实现之间的"契约".

所以,当我创建一个实现时,我必须履行合同.我的问题是,我必须履行的合同究竟是什么？

显然,您必须至少提供与接口具有相同签名的方法.否则代码将无法编译.这是所有的"合同"吗？似乎应该有更多.

例如,我读过一些文章,讨论测试界面与测试特定实现的价值,或两者兼而有之.我认为对接口进行测试非常有价值,这样您就可以知道哪些输入具有预期的输出.在我看来,这也将是"合同"界面的一部分.接口的每个实现都应该从相同的输入产生相同的输出.显然,没有办法在代码中强制执行此合同,但可以通过测试用例强制执行.我的想法在这里错了吗？

最后,实现有哪些副作用？在这里,我主要讨论可能作为实现的一部分发生的任何持久性.假设我有一个实现,它会在执行操作时将一些记录保存到数据库中.这会以某种方式成为界面"合同"的一部分吗？如果是这样,你怎么能执行这份合同？从界面层面来看,我不知道实现实际上在做什么.我所知道的是我给它输入,它给了我一个输出,我可以测试.发生的任何持久性是否也被视为"输出"？如果是这样,我只是看不出如何测试和执行.我是坚持无知的支持者,所以我可以知道应该坚持某些东西,但我不知道它是如何持久存在的.所以,我只是不知道什么时候实际存在的东西.如果您的界面有一些简单的CRUD操作可能很简单,但我想考虑更复杂的界面.

我希望我的问题有道理,有人可以提供一些好的反馈.我想一般性地讨论这个问题,但如果我不清楚我在谈论什么,我可以提供一个具体的例子.

Answer 1

我认为“契约”和“接口”的共同点很少。

界面就像一扇门。典型的人可以通过门，但大象、长颈鹿或汽车却不能。

合同是指你可以确保只有女性、男性或软件开发人员才会进来。

因此，合约定义了行为，而接口定义了传递哪些信息

Answer 2

我认为你对“合同”这个词的看法太大了。

“埃菲尔铁塔”有一个非常具体的“合同设计”理念。就我个人而言，我认为其他语言也会从类似的东西中受益。

通俗地说，您当然可以将 Java 的“接口”视为“契约”。你对 Java 接口的定义当然很好：

至少您必须提供与接口具有相同签名的方法。否则该代码将无法编译。

问：这就是“合同”的全部内容吗？

答：可能不会。这完全取决于您如何定义“合同”；）

但是，恕我直言，Java 接口是一个比可怕的 C++“多重继承”干净得多的功能。两者背后的主要动机之一都是支持“ mixins ”：

类似地，Java 接口也提供了一个干净的、相对简单的、类型保存的解决方案来支持“回调”。

最后建议：请考虑“接口”和“抽象类”之间的区别。这还可能让您对 Java 接口以及如何在自己的代码中有效地使用它们有更多的了解：

接口与抽象类（一般 OO）