假设你有一个界面
public interface Change {
void updateUser();
void deleteUser();
void helpUser();
}
我已经读过接口是Java实现多重继承的方式.您实现了一个接口,然后您可以访问其方法.我不明白的是,这些方法在界面中没有任何主体,所以你需要在你的类中给它们一个主体.因此,如果您的接口由多个类实现,则需要在多个类中为该方法提供一个主体.为什么这比在类中使用单独的方法更好,而不是实现接口？
我知道并理解Java中接口的价值.您编写接口,然后您可以更改您的实现,而无需使用该接口更改任何代码.通常,术语"合同"与接口一起使用.我理解它的方式是接口定义应用程序和实现之间的"契约".
所以,当我创建一个实现时,我必须履行合同.我的问题是,我必须履行的合同究竟是什么？
显然,您必须至少提供与接口具有相同签名的方法.否则代码将无法编译.这是所有的"合同"吗？似乎应该有更多.
例如,我读过一些文章,讨论测试界面与测试特定实现的价值,或两者兼而有之.我认为对接口进行测试非常有价值,这样您就可以知道哪些输入具有预期的输出.在我看来,这也将是"合同"界面的一部分.接口的每个实现都应该从相同的输入产生相同的输出.显然,没有办法在代码中强制执行此合同,但可以通过测试用例强制执行.我的想法在这里错了吗？
最后,实现有哪些副作用？在这里,我主要讨论可能作为实现的一部分发生的任何持久性.假设我有一个实现,它会在执行操作时将一些记录保存到数据库中.这会以某种方式成为界面"合同"的一部分吗？如果是这样,你怎么能执行这份合同？从界面层面来看,我不知道实现实际上在做什么.我所知道的是我给它输入,它给了我一个输出,我可以测试.发生的任何持久性是否也被视为"输出"？如果是这样,我只是看不出如何测试和执行.我是坚持无知的支持者,所以我可以知道应该坚持某些东西,但我不知道它是如何持久存在的.所以,我只是不知道什么时候实际存在的东西.如果您的界面有一些简单的CRUD操作可能很简单,但我想考虑更复杂的界面.
我希望我的问题有道理,有人可以提供一些好的反馈.我想一般性地讨论这个问题,但如果我不清楚我在谈论什么,我可以提供一个具体的例子.
好的,我认为接口是一种强制对象实现一定功能的方法,而不必使用继承.有点像合同.我半看到了他们的观点.
但是,如果您在界面中拥有的是:
public interface animal{
void eat(object food);
}
并且没有这样的实现,那么每次使用你的界面的人都必须从头开始编写它.
如果你要创建一些所有实现这些功能的类,并且实现只是略有不同,那将是一项艰苦的工作.
任何帮助我解决这个问题都是值得赞赏的,因为我知道这非常重要.