我可以用鸭子打字改进这个方法吗?

时间:2008-10-16 17:15:39

标签: ruby-on-rails ruby refactoring duck-typing

希望我没有误解“鸭子打字”的含义,但从我所读到的,这意味着我应该根据对象如何响应方法而不是它的类型/类来编写代码。 / p>

以下是代码:

def convert_hash(hash)
  if hash.keys.all? { |k| k.is_a?(Integer) }
    return hash
  elsif hash.keys.all? { |k| k.is_a?(Property) }
    new_hash = {}
    hash.each_pair {|k,v| new_hash[k.id] = v}
    return new_hash
  else
    raise "Custom attribute keys should be ID's or Property objects"
  end
end

我想要的是确保我最终得到一个散列,其中键是一个表示ActiveRecord对象ID的整数。我并不特别喜欢用all?两次遍历哈希键来确定我是否需要获取ID。

当然,我也接受任何其他改进此代码的建议:)

3 个答案:

答案 0 :(得分:11)

如何编写此方法应取决于您是否期望在正常程序执行过程中抛出异常。如果您想要一个可读的异常消息,因为最终用户可能会看到它,那么手动抛出一个是有意义的。否则,我会做这样的事情:

def convert(hash)
    new_hash = {}
    hash.each_pair { |k,v| new_hash[ k.is_a?(Integer) ? k : k.id ] = v }
    return new_hash
end

这将完成同样的事情,如果数组键没有id字段,你仍然会得到异常。更好的是,这会使用更多的鸭子类型,因为现在任何具有id字段的东西都是可以接受的,这比明确检查某个属性的东西要好。这使您的代码更加灵活,尤其是在进行单元测试时。

我们仍然对整数对象进行了明确的检查,但这种偶然的特殊情况通常是可以接受的,尤其是在检查内置数据类型时。

答案 1 :(得分:3)

鸭子打字真的只是一个细微的多态性版本。在像Java这样的静态类型语言中,您必须创建一个显式接口,告诉编译器特定变量可以接受的所有方法。使用像Ruby这样的动态语言,接口仍然存在于抽象意义上,它们只是隐含的。

问题在于您将两种不同的数据结构接受到一种方法中。使duck typing工作的方法是要求传递给你的方法的所有对象遵循相同的契约(即它总是一个整数到[Foo]对象的哈希。)将带有Property键的哈希转换为正确的结构应该是客户端代码的工作。使用简单的包装类或只包含elseif子句主体的转换函数可以非常轻松地完成这一过程。

最重要的是由调用方法的人来确保他的参数都像你的方法期望他们嘎嘎叫的那样嘎嘎叫。如果他们不这样做,他就是那个需要弄清楚如何让他的火鸡嘎嘎像鸭子一样的人,而不是你。

答案 2 :(得分:0)

  

我想要的是确保我最终得到一个散列,其中键是一个表示ActiveRecord对象ID的整数。

当你在创建/插入哈希时,你应该检查一下。你可以尝试这样的事情:

h = {}
def h.put obj
  self[obj.id]=obj
end

或者

h = {}
def h.[]= key, value
  raise "hell" unless key == value.id
  super
end