Service Objectがアンチパターンである理由とよりよい代替手段(翻訳)

概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Why Service Objects are an Anti-Pattern — INTERSECT 原文公開日: 2018/03/06 著者: Jared White サイト: Intersect — Whitefusion社の技術ブログです。 whitefusion.ioより 画像は元記事からの引用です。 Service Objectがアンチパターンである理由とよりよい代替手段(翻訳) 近年、RailsアプリにService Objectを追加するメリットを説く記事が次から次へと量産されています。私は本記事において、それがなぜ正しくないかを述べたいと思う次第であります。もっとよい方法はあるのです。 私はこれまで、Service Objectに関するネット上の議論にときおり参加しては、まっとうな問題に対する解決方法としてなぜService Objectが正しくないのかという見解を述べてきました。実際、私は多くの場合においてService Objectよりもっとよい解決方法があると考えるのみならず、Service Objectはオブジェクト指向設計原則への配慮が損なわれている兆候を示すアンチパターンとして取り扱っています。 Service Objectを追加したところであんたのRailsコードベースが今より良くなることはねえと言ったらどうするよ? このような深遠なポイントを細切れのツイートやコメント欄を追って理解するのは大変です。そこで私は、私の見解を正確に表すいくつかの現実的なコードを詳しく追って記事にすることにしました。 私が使う「アンチパターン」という用語については、StackOverflowにうまい説明があったので引用します。 「アンチパターン」とは、ソフトウェア開発においてプログラミング上の悪手と考えられる特定のパターンのことです。デザインパターンが、よい開発手法と一般的に考えられている定型化された共通のアプローチであるのと対照的に、アンチパターンは望ましくないものです。 引用元: https://stackoverflow.com/a/980616 私がService Objectを好きになれない理由を説明するために、昔ある顧客のプロジェクトで当時の開発チームが書いたコードを私が継承した中から、いくつかを詳しく見ていくことにします。そのアプリは未だにpublic betaなので当時の状況についてはあまり立ち入ったことは書けませんが、メディア(画像や動画)にレーティングするソーシャルプラットフォームであり、レーティングは特定のコールバックスタイルの操作(データ処理のアルゴリズム更新や、さまざまなユーザーのタイムラインへのアクティビティの追加など)でトリガされる、とだけ言っておきましょう。 比較的シンプルなデータモデルが1つあり、UserオブジェクトとMediaオブジェクトにbelongs_toで属しているRatingオブジェクトをそこに作成できます。以下のコード例はいずれもproductionファイルそのままではなく、抜粋です。 class Rating < ActiveRecord::Base belongs_to :user belongs_to :media end class Media < ActiveRecord::Base has_many … Continue reading Service Objectがアンチパターンである理由とよりよい代替手段(翻訳)