1

所以，假设我正在编写一个 API 来制作美味的糖霜蛋糕。这一切都很好并且记录在案，但偶尔会出现错误，或者用户可能正在通过 IRB 探索库，并且在他们进行原型设计时使用了一个变量。

这就是我通常向调用者指示参数不能为 nil / 具有其他约束的方式：

# Cake.rb
def make_cake(cake_type, *arguments)
  raise "cake_type required!" unless !cake_type.nil?
  raise "cake_type must be in KNOWN_CAKES" unless KNOWN_CAKES.include?(cake_type)
  # blah blah blah
end

但是，我最近考虑过这样的事情，使用rspec-expectationsgem：

# Cake.rb
include RSpec::Matchers
def make_cake(cake_type, *arguments)
  cake_type.should_not be_nil, "cake_type required"
  KNOWN_CAKES.should include(cake_type), "cake_type not found"
end

优点：

  • 简洁的 DSL 让针对 API 进行开发的人非常容易阅读。
  • RSpec::Expectations::ExpectationNotMetError 有一些很好的异常格式，为您提供预期值与实际接收值。

缺点（s？）：

  • RSpec::Expectations::ExpectationNotMetError 可能有点过于冗长。

所以，这种方法：好主意，还是坏主意？它违反了哪些设计原则？

4

1 回答 1

0

作为调用者，如果从 API 调用中返回 RSpec 异常，我会感到惊讶。

你真的收获很多吗？如果您只是更改为raise 'cake type required!' if cake_type.nil?. 对我来说，似乎比您的原始代码更清楚。也许您这样写是为了unless两次都使用？

难道你不能简单地通过提出更好的消息来实现你传回预期/接收值的目标 - 也许通过你自己的异常类？

于 2011-09-30T21:33:03.533 回答