Ruby和duck打字:合同设计不可能？

如果你只是想获得一个文件,你会称它为get_file或get_first_file或等等.如果你正在做一些更复杂的事情,比如返回FileWrapper对象而不仅仅是字符串,那么有一个非常好的解决方案:

# returns a list of FileWrapper objects
def get_files_in_directory( dir )
end

好歹.你不能像在java中那样强制执行ruby中的契约,但这是更广泛的一部分,即你不能像在java中那样在ruby中强制执行任何操作.由于ruby的语法更具表现力,你可以更清楚地编写类似英语的代码,告诉其他人你的合同是什么(其中为你节省了几千个尖括号).

我相信这是一场净胜利.您可以使用新发现的空闲时间编写一些规格和测试,并在一天结束时提供更好的产品.

我认为虽然Java方法为您提供了更多信息,但它并没有为您提供足够的信息来轻松编程.
例如,字符串列表只是文件名还是完全限定路径？

鉴于此,您的Ruby没有提供足够信息的论点也适用于Java.
您仍然依赖于阅读文档,查看源代码,或调用方法并查看其输出(当然还有不错的测试).

虽然我在编写Java代码时喜欢静态类型,但是没有理由不能坚持Ruby代码(或任何类型的代码)的深思熟虑的先决条件.当我真的需要坚持方法参数的前提条件(在Ruby中)时,我很乐意编写一个可能引发运行时异常的条件来警告程序员错误.我甚至通过写作给自己一个静态类型的外观:

def get_files_in(directories)
   unless File.directory? directories
      raise ArgumentError, "directories should be a file directory, you bozo :)"
   end
   # rest of my block
end

在我看来,这种语言无法阻止你按合同进行设计.相反,在我看来,这取决于开发人员.

(顺便说一句,"bozo"真的是指你的:)

通过duck-typing验证方法:

i = {}
=> {}
i.methods.sort
=> ["==", "===", "=~", "[]", "[]=", "__id__", "__send__", "all?", "any?", "class", "clear", "clone", "collect", "default", "default=", "default_proc", "delete", "delete_if", "detect", "display", "dup", "each", "each_key", "each_pair", "each_value", "each_with_index", "empty?", "entries", "eql?", "equal?", "extend", "fetch", "find", "find_all", "freeze", "frozen?", "gem", "grep", "has_key?", "has_value?", "hash", "id", "include?", "index", "indexes", "indices", "inject", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "invert", "is_a?", "key?", "keys", "kind_of?", "length", "map", "max", "member?", "merge", "merge!", "method", "methods", "min", "nil?", "object_id", "partition", "private_methods", "protected_methods", "public_methods", "rehash", "reject", "reject!", "replace", "require", "respond_to?", "select", "send", "shift", "singleton_methods", "size", "sort", "sort_by", "store", "taint", "tainted?", "to_a", "to_hash", "to_s", "type", "untaint", "update", "value?", "values", "values_at", "zip"]
i.respond_to?('keys')
=> true
i.respond_to?('get_files_in')  
=> false

一旦你理解了这种推理,方法签名就没有意义,因为你可以动态地在函数中测试它们.(这部分是由于无法进行基于签名匹配的功能调度,但这更灵活,因为您可以定义无限的签名组合)

 def get_files_in(directories)
    fail "Not a List" unless directories.instance_of?('List')
 end

 def example2( *params ) 
    lists = params.map{|x| (x.instance_of?(List))?x:nil }.compact 
    fail "No list" unless lists.length > 0
    p lists[0] 
 end

x = List.new
get_files_in(x)
example2( 'this', 'should', 'still' , 1,2,3,4,5,'work' , x )

如果您想要更加可靠的测试,可以尝试RSpec进行行为驱动的开发.