Ruby 契约式编程 DbC 的价值

chenge · 2013年05月04日 · 最后由 bhuztez 回复于 2013年05月05日 · 3398 次阅读

这个似乎不太流行,不过还是觉得有价值。

  • 先验条件补充了参数的要求,并过滤了非法参数,有文档作用
  • 验证条件可以减少出错的几率,先验条件挡掉了参数错误
  • 减少难以解释的错误的几率,基本排除不可预知的参数和组合错误

这个不能取代单元测试,反之亦然。

module Kernel
    def assert_param x
            raise Exception.new 'param error' if !x
    end
    def assert x
            raise Exception.new 'error' if !x
    end
end

def pl x 
    #先验条件, 可以注释掉对比下哪一个错误更容易理解
    assert_param x.class == String
   #

    #main
    p x.upcase
    res = 1

    #后验条件
    assert res > 0
end

pl 1
pl 'x'

你说的是 Constraint programming 吧?那你的理解不对

#1 楼 @wushexu Design by Contract

#2 楼 @chenge 哦,我对中文名词不敏感

在大项目(时间长 代码量大 人员变动非常厉害)的项目下这种方法是否可能增加很多额外的工作量?它迫使程序员在不熟悉项目的情况下 1. 要做出契约 2. 要修改之前别人做的契约 否则难以做出变动。

#2 楼 @chenge 原来楼主说的是这个。。今天碰巧才看到这个东西(PS:果然这种词汇不应该翻译比较好啊)

人肉静态类型编译器

#4 楼 @iBachue 感觉好像就是把文档强制性写到代码里了 而且写错还不行

#6 楼 @Rei 这个比喻很到位 啊。。

感觉直接去写渣瓦就好了

#6 楼 @Rei #8 楼 @Tony612 不是静态,是运行时检查,比如你前不久的参数错误 hash={}就很容易发现。

我修改了下例子,可以去掉那个参数检查,对比下出错提示,看哪一个更容易。

#4 楼 @iBachue 具体怎么写,还需要考虑。可考虑选择性地写先验。

effiel 那种语言的范式吧

#10 楼 @chenge 就是因为运行时检查,所以我那个错误写法一直没发现,我调用方法的时候一直都有赋值一个 hash。

顶楼就是静态类型检查,需要的话直接用静态语言。

#12 楼 @Rei 确实不能查出那个 hash 错误。不限于类型检查,也可以包括值检查。

#13 楼 @bhuztez Ada 对这个是如何支持的?有什么大的应用么?

#14 楼 @chenge 值检查写少了覆盖面不全,写多了比逻辑代码还多,最后抽取单独文件变成单元测试。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号