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にはいくつかの優れた例外フォーマットがあり、期待値と実際の受信値を比較できます。

短所：

  • RSpec :: Expectations::ExpectationNotMetErrorは少し冗長すぎる可能性があります。

だから、このアプローチ：良いアイデア、または悪いアイデア？どのような設計原則に違反していますか？

4

1 に答える 1

0

呼び出し元として、API 呼び出しから RSpec 例外が返されたら驚くでしょう。

あなたは本当に多くを得ますか？に変更するとどうなりますかraise 'cake type required!' if cake_type.nil?。元のコードよりも読みやすいようです。unlessおそらく、両方の時間を使用するようにそのように書いたのでしょうか？

おそらく独自の例外クラスを介して、より良いメッセージを生成するだけで、期待値/受信値を返すという目標を達成できませんでしたか?

于 2011-09-30T21:33:03.533 に答える