定义新 API 时使用 struct 作为参数的优点/缺点答案

【问题标题】：Advantages/disadvantages to using struct as a parameter while defining new API定义新 API 时使用 struct 作为参数的优点/缺点
【发布时间】：2011-09-23 13:55:12
【问题描述】：

我正在编写的 API 用于从 ActiveRecord 继承的 Ruby 类。我正在尝试编写静态方法以避免泄漏 ActiveRecord 实例。所有 API 现在都需要元组来唯一标识数据库行。

拥有以下形式的 API 是否是个好主意：

API1(abc, def, ....) API2(abc, def, ....) 等等

或者我应该定义一个带有字段的结构来帮助未来的变化？

非常欢迎任何其他想法！

【问题讨论】：

也希望能提供设计意见。在某些方面，使用散列而不是单个参数的想法是好是坏？

标签： ruby api parameters struct

【解决方案1】：

在 Ruby 中使用 struct 会很奇怪，使用 Hash 是正常的：

def self.api1(options)
    # Look at options[:abc], options[:def], ...
end

然后可以使用这样的命名参数调用它：

C.api1 :abc => 'abc', :def => '...'

易于扩展，常见的 Ruby 实践，并且易于使某些参数可选。

【讨论】：

感谢使用哈希的想法。就我而言，这些参数并不是真正可选的，因为它们唯一地标识了一条数据库记录。
@Smitten：您不必将它们称为选项，您可以（并且应该）验证您需要的一切都在那里。使用散列是处理长参数列表的一种简单方法。您可以使用一个或多个参数列表，但如果有多个参数，它将变得笨拙。 OTOH，Ruby 会抱怨使用简单位置参数的参数数量错误。

【解决方案2】：

继续 mu 所描述的内容，这是一个常见的 Ruby 习惯用法，您将看到它让一个方法为自己设置一些默认选项，然后将该方法接收到的选项合并到该哈希中。这样您就可以确保始终存在一些最少的选项列表：

def self.api1(options={})
  default_options = { :foo => 'bar', :baz => nil }
  options = default_options.merge options
  # Now include your code and you can assume that options[:foo] and options[:bar] are there
end

例如，当您的方法输出:baz 的值时，这会派上用场。现在你不需要先检查它是否存在，你可以输出它知道它永远存在。

【讨论】：