2

私はルビーで取り組んでいるプロジェクトを持っています、そしてそれは何人かの労働者からの多額の仕事を必要とします。ほとんどのビジネスロジックはこれらのワーカーに含まれており、非常に複雑になっています。私が考案した手法は、composeメソッドのパターンをモデル化していますが、状態を維持するためにインスタンス変数に大きく依存しています。私がこれを設定した方法は論理的に思えますが、これが間違っているかどうか、またはこれを設定できる最もクリーンな方法ではないかどうかについて、コミュニティからフィードバックを受け取りたいと思います。

私は基本的に、一種のスイッチとしてワーカー実行（Sidekiq）メソッドを使用しています

def perform(transaction_id, data, account_id)
  @transaction_id = transaction_id
  @data           = data
  @account        = Account.new(account_id)

  @campaign_tag   = nil
  @match_str      = nil
  @options        = nil

  has_starter_tag     || return
  find_campaign       || return
  determine_options   || return
  find_active_option  || return
  reservation_over    || return
  already_filled      || return

  send_to_inventory
end

各メソッドは同じロジックに従います。ルールを確認し、満足できない場合は、アクションを実行し（電子メールを送信するなど）、falseを返し、実行を停止します。満足のいく場合は、トランザクションを完了してtrueを返すために必要ないくつかのivarデータを保存し、次のステップに進みます。

def has_starter_tag
  result = true

  @campaign_tag = find_starter_tag(@account, @data[:variable])
  if !@campaign_tag
    result = false
    send_email_about_badness
    log_some_stuff
  end

  result
end

このコードをテストするために、各メソッドが依存するインスタンス変数をスタブします。私のテストはインターフェースではなく実装を認識しているので、これはコードの臭いであることを理解しています。そうは言っても、私はこれらのメソッドのすっきりとしたインターフェースが好きで、ソースをスキャンして何が起こっているのかを正確に知ることができると感じています。

私が間違っている場合、誰かが時間をかけてこれを行う正しい方法（または少なくとも別の方法）を説明してもらえますか？私はいつも、すべてが互いに積み重なっているように見える多くの小さなステップを実行しなければならないオブジェクトを処理する方法を理解するのに問題がありました。

4

1 に答える 1

1

私の直感は、あなたがこれをいくらかオーバーアーキテクチャにしようとしているということです。

あなたが説明するものはデザインパターンとしてカウントされません.必要な機能をいくつかの個別のメソッドに分離するだけです. 問題は、メソッドが互いに非常に密接に結合されているため、それらを分離しても機能を「グループ化」する以外の目的にはあまり役立たないことです。関数に共通しているように見える唯一のことは、何かをチェックし、チェックが失敗したジョブをキャンセルすることです。繰り返し機能は別として、すべてのコードを 1 つの関数に入れ、個々の部分を空白行で区切ることによって、ほぼ同じ効果を得ることができます。

コードで使用する OOP ソリューションまたは設計パターンを見つけることは、非生産的である場合があります。結局のところ、本当に重要なことは、それがアドバンテージを提供するかどうかです。コードを節約できますか？コードの保守と拡張を容易にしますか? (コードは簡単に拡張できる必要がありますか?) OOP のために OOP を使おうとして夢中になりすぎないでください。

于 2012-05-24T00:51:01.363 に答える