契约设计的一些想法

契约设计由来已久,各语言的支持方式与级别不尽相同,
契约元素包括:
前验条件(precondition)
后验条件(postcondition)
不变式(invariant)
这里只考虑前验条件的:
需求定义(require)
保证合法性(ensure)
函数的签名算是需求的最基本定义了。
对于合法性的保证,一般采用断言。
Java在1.4以前,大家只能靠简单的函数封装实现。
如,在函数开头:
if (param < 0)
throw new IllegalArgumentException("param < 0");
或进行简单封装:
Assert.notLessThan(param, 0);
从1.4开始,Java对断言提供语言级别的支持。加入了关键字assert。
如:
assert(param < 0);
因为是语言级别的支持,断言可在生产环境中被擦拭掉,以保证性能。

废话就说到这了,我想说的是,
是否应该在需求定义时就尽可能的保证合法性。
也就是在函数签名上保证合法性,而不是断言。
断言信息需要通过文档才能被调用者获悉。
而函数签名能够更明确。
如:
setSize(Integer size) {
assert(size > 0);
...
}
改为:
setSize(PositiveInteger size) {
...
}
当然,这样会多出很多类型定义。
而这些语言是否应给予更多便利支持?

泛型就是一种方式:
setUsers(Map users) {
for(Iterator iterator = users.entrySet.iterator(); iterator.hasNext();) {
Map.Entry entry = (Map.Entry)iterator.next();
assert(entry.getKey() instanceof String);
assert(entry.getValue() instanceof User);
}
...
}
这个断言是很费时的。
而用泛型:
setUsers(Map<String, User> users) {
...
}
泛型一定程度上减少了类型定义的烦琐。
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值