使用哈希表作为函数输入

Question

我正在为正在为Ruby中使用的工具编写一些API的组中工作。编写API方法时，我的许多团队成员使用散列表作为方法的唯一参数，而我用指定的每个值编写我的方法。

例如，一个类苹果的定义为：

class Apple 
    @commonName 
    @volume 
    @color 
end 

我会实例化类方法：

Apple.new(commonName, volume, color) 

我的队友们会写这样的方法看上去像：

Apple.new({"commonName"=>commonName, "volume"=>volume, "color"=>color) 

我不喜欢使用散列表作为输入。对我来说似乎不必要的庞大，并没有增加任何清晰的代码。虽然在这个例子中看起来并不算什么大问题，但我们的一些方法有超过10个参数，并且通常会有哈希表嵌套在其他哈希表中。我还注意到以这种方式使用哈希表在公共API中非常少见（net/telnet是我现在能想到的唯一例外）。

问题：我可以给我的团队成员什么样的参数，以便不使用散列表作为输入参数。代码的庞大程度并不充分（他们不害怕编写200-400字符行），并且过多的内存/处理开销将不起作用，因为它不会成为我们的工具使用方式的问题。

Answer 1

实际上，如果你的方法需要超过10个参数，你应该重新设计你的课程，或者吃掉污垢并使用哈希值。对于任何需要4个以上参数的方法，使用典型参数在调用方法时可能会违反直觉，因为您必须正确记住顺序。

我认为最好的解决方案是简单地重新设计这样的方法，并使用像建设者或流利的模式。

Answer 2

首先，你应该让他们使用字符串而不是符号来表示散列键。

使用散列的一个问题是，您必须检查所有适当的键是否在其中。这对于可选参数非常有用，但对于强制性参数，为什么不使用该语言的内置功能呢？例如，用自己的方法，如果我这样做，会发生什么：

Apple.new({"commonName"=>commonName, "volume"=>volume}) 

然而，随着Apple.new(commonName, volume)，你知道你会得到一个ArgumentError。

Answer 3

命名参数使更多的自我记录代码，这是很好的。但除此之外，没有太大的区别。哈希允许更多的灵活性，特别是如果你开始做任何方法别名。此外，ActiveSupport中的各种哈希方法使设置默认值和验证输入非常轻松。我想这可能不是你正在寻找的答案。