我一直在考虑创建一个 Java 框架,允许程序员在接口上指定不变量(前置条件和后置条件)。目的是使代码更加健壮并减少需要为同一接口的不同实现编写的单元测试的数量。
我设想创建某种方法,用程序员也会编写的不变量来注释方法。例如
interface Sort {
int [] sort(int [] nums);
}
将用注释装饰,以确保任何实现都返回排序列表。此注释将链接到可以在编译时针对任何实现运行的单元测试。
这是一个疯狂的想法还是对更广泛的编程社区有用?
我一直在考虑创建一个 Java 框架,允许程序员在接口上指定不变量(前置条件和后置条件)。目的是使代码更加健壮并减少需要为同一接口的不同实现编写的单元测试的数量。
我设想创建某种方法,用程序员也会编写的不变量来注释方法。例如
interface Sort {
int [] sort(int [] nums);
}
将用注释装饰,以确保任何实现都返回排序列表。此注释将链接到可以在编译时针对任何实现运行的单元测试。
这是一个疯狂的想法还是对更广泛的编程社区有用?
我认为按合同设计是一个好主意,我已经浏览了在 Java 中提供该功能的框架。我认为让我退缩的是,从团队那里获得对这类框架的支持可能很困难。我认为它被认为只是学术兴趣,这很奇怪,因为它实际上就像在代码中嵌入单元测试一样。
Java 在这个方向上的主要点头,断言语句,已经存在了好几年,但我很少看到它被使用——通常只在我自己编写的代码中使用!使用断言(尤其是与单元测试结合使用)有很多里程,我发现使用它们的一些错误,只是可惜人们不使用它们。
干杯,
伊恩。
我认为 Bertrand Meyer 的契约式编程基本上已经死了。他在 Eiffel 中建立了前置条件和后置条件,但这种语言在使用规模上低于拉丁语。
那里有合约库的 Java 编程;承包商是其中之一。但它的日子已经过去了。事实是,即使是 Eiffel 也有办法在生产中关闭它们,因为运行时成本不值得收益。
Stack Overflow 上只有 6 个 Eiffel 问题 - 确实是一小部分。如果您搜索带有“合同”的 SO 标签,您会看到一个非常小的数字。对这个网站上的主题不太感兴趣。它声称吸引了世界上最大的专业程序员观众。
多么伟大的编程理念不疯狂!!!我绝对认为它会很有用。