我知道并理解Java中接口的价值。您编写接口,然后您可以更改您的实现,而无需使用该接口更改任何代码。通常,术语“合同”与接口一起使用。我理解它的方式是接口定义了应用程序和实现之间的“契约”。
因此,当我创建一个实现时,我必须履行合同。我的问题是,我必须履行的合同究竟是什么?
显然,您必须至少提供与接口具有相同签名的方法。否则代码将无法编译。这是所有的“合同”吗?似乎应该有更多。
例如,我读过一些文章,讨论测试界面与测试特定实现的价值,或两者兼而有之。我认为对接口进行测试非常有价值,这样您就可以知道哪些输入具有预期的输出。在我看来,这也将是“合同”界面的一部分。接口的每个实现都应该从相同的输入产生相同的输出。显然,没有办法在代码中强制执行此合同,但可以通过测试用例强制执行。我在这里思考错了吗?
最后,实施有哪些副作用?在这里,我主要讨论可能作为实现的一部分发生的任何持久性。假设我有一个实现,它会在执行操作时将一些记录保存到数据库中。这会以某种方式成为界面“合同”的一部分吗?如果是这样,你怎么能执行这份合同?从界面层面来看,我不知道实现实际上在做什么。我所知道的是我给它输入,它给了我一个输出,我可以测试。发生的任何持久性是否也被视为“输出”?如果是这样,我只是看不出如何测试和执行。我是持久性无知的支持者,所以我可以知道应该被持久化,但我不知道 是如何持久存在的。所以,我只是不知道什么时候实际存在的东西。如果您的界面有一些简单的CRUD操作可能很简单,但我想考虑更复杂的界面。
我希望我的问题有道理,有人可以提供一些好的反馈。我想一般性地讨论这个问题,但如果我不清楚我在说什么,我可以提供一个具体的例子。
答案 0 :(得分:3)
我认为“合约”和“界面”的共同点很少。
界面就像一扇门。 门可以通过典型的人类,但不能通过大象,长颈鹿或汽车。
合同就是你可以通过门保证 只有女性,男性或软件开发人员才会来。
所以合约定义BEHAVIOR,而接口定义传递哪些信息
答案 1 :(得分:2)
我认为你对“合同”一词的处理太大了。
“Eiffel”具有非常具体的“按合同设计”的理念。就个人而言,我认为其他语言会从类似的东西中受益。
非正式地,您当然可以将Java的“接口”视为“合同”。您对Java接口的定义肯定是好的:
问:这是所有的“合同”吗? 答:可能不是。这一切都取决于你如何定义“合同”;)至少你必须提供具有相同签名的方法 界面。否则代码将无法编译。
但是,恕我直言,Java接口是一个很多更清洁的功能,而不是C ++“多重继承”的恐怖。其中一个主要动机是支持“mixins”:
同样,Java接口也提供了一个干净,相对简单的类型保存解决方案来支持“callbacks”。
最后建议:请考虑“界面”和“抽象类”之间的区别。这也可以让您更深入地了解Java接口,以及如何在您自己的代码中有效地使用它们:
答案 2 :(得分:0)
因此合同是方法签名+与函数/类相关的任何文档。从中可以看出,接口与java关键字interface
的含义并不相同。界面是允许您与另一个系统交互的任何东西。那么关于如何履行声明为如此的函数的合同的问题:
/** Throws IllegalArgumentException if s is null.
Converts the input <b>s</b> into an {@link Integer} */
function go(String s);
您需要按如下方式编写实现:
function go(String s)
{
if(null == s) throw new IllegalArgumentException();
int i = Integer.parseInt(s);
}
Contrived yes,但这应解释如何实施合同并遵守合同。