我可以用鸭子打字改进这种方法吗？答案

【问题标题】：Could I improve this method with duck typing?我可以用鸭子打字改进这种方法吗？
【发布时间】：2008-10-16 17:15:38
【问题描述】：

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

代码如下：

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。

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

【问题讨论】：

以前从未听说过“鸭子打字”。你是从哪里看到的？
@Brian, en.wikipedia.org/wiki/Duck_typing

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

【解决方案1】：

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

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 字段的东西都是可以接受的，这比显式检查是否是属性要好。这使您的代码更加灵活，尤其是在单元测试时。

我们仍然对整数对象进行显式检查，但这种偶尔出现的特殊情况通常是可以接受的，尤其是在检查内置数据类型时。

【讨论】：

伟大的，描述性的答案，带有一些非常 Rubyish 的代码，Eli。非常感谢您的回复。
问题在于 Ruby 中的每个对象都有一个#id 方法。它在 Object 上定义，并在 Ruby 解释器中为该 Object 提供唯一的引用。但它已被弃用，因此虽然您会收到警告，但不会收到异常。

【解决方案2】：

Duck 类型实际上只是多态性的细微差别。在像 Java 这样的静态类型语言中，您必须创建一个显式接口，告诉编译器特定变量可以接受的所有方法。对于像 Ruby 这样的动态语言，接口仍然存在于抽象意义上，它们只是隐含的。

问题在于您在一种方法中接受了两种不同的数据结构。使鸭子类型工作的方法是要求传递给您的方法的所有对象都遵守相同的约定（即，它始终是整数到 [Foo] 对象的散列。）将带有属性键的散列转换为正确的结构应该是客户端代码的工作。这可以通过一个简单的包装类或仅由 elseif 子句主体组成的转换函数轻松完成。

归根结底，这取决于调用该方法的人，以确保他的参数都按您的方法期望它们发出的嘎嘎声。如果他们不这样做，那么他就是需要弄清楚如何让他的火鸡像鸭子一样嘎嘎叫的人，而不是你。

【讨论】：

【解决方案3】：

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

您可能应该在创建/插入哈希时检查这一点。你可以试试这样的：

h = {} def h.put 对象自我[obj.id]=obj 结尾

或许

h = {} def h.[]= 键，值引发“地狱”，除非 key == value.id 极好的结尾

【讨论】：