合同究竟是什么？
我知道并理解Java中接口的价值。 你编码到接口，然后你可以改变你的实现，而不必使用接口来改变任何代码。 通常术语“合同”与接口一起使用。 我的理解是接口定义了应用程序和实现之间的“契约”。
所以，当我创建一个实现时，我必须履行合同。 我的问题是，我必须履行的合同到底是什么？
显然，至少你必须提供与接口相同的签名方法。 该代码不会另外编译。 所有的“合同”都包含在内吗？ 似乎应该有更多。
例如，我已经阅读了关于测试对接口的价值与测试特定实现或者两者兼有的文章。 我认为测试界面非常有价值，因此您可以了解哪些输入具有预期的输出。 在我看来，这也将成为界面“契约”的一部分。 接口的每个实现应该从相同的输入产生相同的输出。 很明显，在代码中没有办法强制执行这个合同，但是它可以通过测试用例来执行。 我在这里想错了吗？
最后，实现有哪些副作用？ 在这里，我主要谈论作为实现的一部分可能发生的任何持久性。 假设我有一个实现，它在执行操作时将一些记录保存到数据库。 这是否会成为界面“契约”的一部分？ 如果是这样，你怎么能执行这个合同？ 从界面层面来说，我不知道实现实际上在做什么。 我所知道的是我给它的输入，它给了我一个输出，我可以测试。 发生的任何持续性是否也被认为是“输出”？ 如果是这样，我只是不明白如何测试和强制执行。 我是坚持无知的支持者，所以我可以知道应该坚持下去，但我不知道它是如何坚持下去的。 所以，我只是不知道什么时候真的存在。 如果你的界面有一些简单的CRUD操作可能很简单，但我想考虑更复杂的界面。
我希望我的问题有意义，有人可以提供一些好的反馈意见。 我想一般性地讨论这个问题，但是如果我不清楚我在说什么，我可以提供一个具体的例子。
我认为“契约”和“接口”的共同点很少。
一个界面就像一扇门。 一扇门可能会通过典型的人类，但不是大象，长颈鹿或汽车。
一个合同就是当你可以确保只有女性，男性或软件开发者才会来。
因此，一个合同定义了BEHAVIOR，而接口定义了哪些信息被传递
我认为你对“合同”这个词做了太大的处理。
“埃菲尔”有一个非常具体的“合约设计”理念。 就个人而言，我认为其他语言会从类似的东西中受益。
非正式地说，你当然可以把Java的“接口”看作是“契约”。 您定义的Java接口当然是好的：
至少必须提供与界面相同的签名方法。 该代码不会另外编译。
问：所有的“合同”是否都包含在内？
答：可能不会。 这一切都取决于你如何定义“合同”;）
但是，恕我直言，Java接口比C ++“多重继承”的恐怖更清晰。 两者背后的主要动机之一是支持“mixins”：
同样，Java接口也提供了一个干净的，相对简单的节省类型的解决方案来支持“回调”。
最终建议：请考虑“界面”和“抽象类”之间的区别。 这也可能让您更深入地了解Java接口，以及如何在自己的代码中有效使用它们：
界面与抽象类（通用OO）
所以合约是方法签名+与函数/类相关的任何文档。 从这个角度来看，接口并不意味着与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);
}
有争议的是，但这应该解释如何执行合同并遵守合同。
链接地址: http://www.djcxy.com/p/58667.html