7大規模なActiveRecordモデルのリファクタリング

翻訳者から： 7つのパターンと題されたFat ActiveRecord ModelsをリファクタリングするCode Climateブログの記事の無料翻訳をお届けします。

Code Climateは、Ruby on Railsアプリケーションのコード品質とセキュリティを分析するための強力なツールです。

はじめに

開発者がRailsコードの品質を改善するためにCode Climateを使用し始めるとき、多くのコードを持つモデルは大きなアプリケーションを維持するときに問題を引き起こすため、モデルのコードの「膨張」を避ける必要があります。 ドメインロジックをモデルにカプセル化することは、そのロジックをコントローラーに配置するよりも優れていますが、そのようなモデルは通常、 単一責任原則に違反します。 たとえば、ユーザーに関連するすべてをUserクラスに配置する場合、これが唯一の責任ではありません。



初期段階でSRPの原則に従うことは非常に簡単です。モデルクラスはデータベースおよび関係との相互作用のみを制御しますが、徐々に成長し、元々リポジトリとの相互作用を担当していたオブジェクトが実際にすべてのビジネスロジックの所有者になります。 1〜2年後、パブリックインターフェイスに500行を超えるコードと数百のメソッドを持つUserクラスを取得します。 このコードを理解することは非常に困難です。



アプリケーションの内部の複雑さが増すと（機能の追加）、小さなオブジェクトまたはモジュールのセット間でコードを配布する必要があります。 これには、常にリファクタリングが必要です。 この原則に従うと、明確に定義されたインターフェースを備えた小さくて応答性の高いオブジェクトのセットができます。



RailsでOOPの原則に従うことは非常に難しいと思うかもしれません。 同じことを考えましたが、しばらく時間をかけて実験した結果、フレームワークとしてのRailsは絶対にOOPに干渉しないことがわかりました。 全体の責任は、Railsの契約、またはActiveRecordの複雑さの管理（従うのが容易なモデル）を管理する契約の欠如です。 幸いなことに、この場合、オブジェクト指向の原則と実践を適用できます。

モデルからミックスインを選択しないでください

このオプションをすぐに除外しましょう。 大規模なモデルのメソッドの一部を懸念またはモジュールに移動することはお勧めしません。これらは同じモデルに含まれます。 継承よりも構成が望ましい。 ミックスインを使用することは、隅にあるゴミを押して汚れた部屋を掃除するようなものです。 最初はきれいに見えますが、このような「コーナー」は、モデル内のすでに複雑なロジックの理解を複雑にします。



さあ、リフォーリングを始めましょう！

リファクタリング

1.値オブジェクトを強調表示する

値オブジェクトは、含まれている値によって別のオブジェクトと簡単に比較できる単純なオブジェクトです。 通常、そのようなオブジェクトは不変です。 日付、URI、およびパス名はRuby標準ライブラリの値オブジェクトの例ですが、アプリケーションはオブジェクト（ドメイン固有の値）を定義できます（ほぼ確実に定義できます）。 それらをモデルと区別することは、最も単純なリファクタリングの1つです。



Railsでは、値オブジェクトは、関連するロジックを持つ属性または小さな属性グループとして使用するのに最適です。 テキストフィールドまたはカウンタ以上の属性は、個別のクラスとして割り当てられる優れた候補です。



たとえば、メッセージングアプリケーションではPhoneNumber値オブジェクトを使用でき、マネートランザクションアプリケーションではMoney値オブジェクトを使用できます。 Code Climateにはオブジェクトがあります-Ratingという値です。これは、すべてのクラスまたはモジュールが受け取るAからFまでの単純な評価スケールです。 （最初はこれが行われました）通常の文字列のインスタンスを使用できましたが、 Ratingクラスを使用すると、データに動作を追加できます。

class Rating include Comparable def self.from_cost(cost) if cost <= 2 new("A") elsif cost <= 4 new("B") elsif cost <= 8 new("C") elsif cost <= 16 new("D") else new("F") end end def initialize(letter) @letter = letter end def better_than?(other) self > other end def <=>(other) other.to_s <=> to_s end def hash @letter.hash end def eql?(other) to_s == other.to_s end def to_s @letter.to_s end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ConstantSnapshotクラスの各インスタンスは、次のように、そのパブリックインターフェイスで評価オブジェクトへのアクセスを提供します。

 class ConstantSnapshot < ActiveRecord::Base # … def rating @rating ||= Rating.from_cost(cost) end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ConstantSnapshotクラスのサイズを縮小することに加えて、このアプローチにはさらにいくつかの利点があります。

• #Worse_thanメソッド？ と#better_than？ 組み込みのRuby演算子>および<
  
  
• #hashおよび#eqlメソッドを定義していますか？ クラスRatingのオブジェクトをハッシュキーとして使用できるようにします。 CodeClimateはこれを使用して、 Enumberable＃group_byを使用して評価することにより、クラスとモジュールをグループ化します。
  
  
• #to_sメソッドを使用すると、追加の労力なしで、クラスRatingのオブジェクトを文字列に補間できます
  
  
• このクラスは、指定された「修正価格」（指定されたクラスのすべての「匂い」を除去するのに必要な時間）に対する正しい評価を返すファクトリメソッドの便利な場所です。
  
  

2.サービスオブジェクトの選択（サービスオブジェクト）

システムの一部のアクションは、サービスオブジェクトへのカプセル化を正当化します。 アクションが1つ以上の基準を満たす場合、このアプローチを使用します。

• 複雑なアクション（たとえば、会計期間の終わりに元帳を閉じる）
  
  
• アクションには、いくつかのモデルでの作業が含まれます（たとえば、電子購入にはOrder 、 CreditCardおよびCustomerクラスのオブジェクトが含まれる場合があります）
  
  
• アクションは外部サービスと対話します（たとえば、ソーシャルネットワークでの共有）
  
  
• アクションは、基礎となるモデルに直接関連していません（たとえば、一定期間後に期限切れの注文をクリアするなど）
  
  
• このアクションを実行するには、いくつかの方法があります（アクセストークンまたはパスワードを使用した認証など）。 この場合、GoFパターン戦略を使用する必要があります。
  
  

たとえば、 User＃authenticateメソッドをUserAuthenticatorクラスに転送できます 。

 class UserAuthenticator def initialize(user) @user = user end def authenticate(unencrypted_password) return false unless @user if BCrypt::Password.new(unencrypted_password) == @user.password_digest @user else false end end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、 SessionsControllerは次のようになります。

 class SessionsController < ApplicationController def create user = User.where(email: params[:email]).first if UserAuthenticator.new(user).authenticate(params[:password]) self.current_user = user redirect_to dashboard_path else flash[:alert] = "Login failed." render "new" end end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3.フォームオブジェクトの選択（フォームオブジェクト）

1つのフォーム送信で複数のモデルを更新できる場合、このアクションはフォームオブジェクトにカプセル化できます。 これは、 accepts_nested_attributes_forを使用するよりもずっときれいです。 良い例は、登録フォームの送信です。その結果、 会社とユーザーのレコードを作成する必要があります 。

 class Signup include Virtus extend ActiveModel::Naming include ActiveModel::Conversion include ActiveModel::Validations attr_reader :user attr_reader :company attribute :name, String attribute :company_name, String attribute :email, String validates :email, presence: true # … more validations … # Forms are never themselves persisted def persisted? false end def save if valid? persist! true else false end end private def persist! @company = Company.create!(name: company_name) @user = @company.users.create!(name: name, email: email) end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ActiveRecordと同様の属性動作を実現するために、gem Virtusを使用します。 フォームオブジェクトは通常のモデルのように見えるため、コントローラーは変更されません。

 class SignupsController < ApplicationController def create @signup = Signup.new(params[:signup]) if @signup.save redirect_to dashboard_path else render "new" end end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

示されている例のように、これは単純な場合にはうまく機能しますが、データベースと対話するロジックが複雑になりすぎる場合、このアプローチをサービスオブジェクトの作成と組み合わせることができます。 さらに、検証は多くの場合コンテキスト依存であるため、すべての検証をモデルに入れるのではなく、使用場所で直接決定できます。たとえば、ユーザーのパスワードの検証は、新しいユーザーを作成するときとパスワードを変更するときにのみ必要です、いいえユーザーデータが変更されるたびにこれを確認する必要があります（ユーザーデータの変更とパスワードの変更フォームを1つのビューに入れないのですか？）

4.クエリオブジェクトの強調表示

複雑なSQLクエリが（静的メソッドとスコープに）表示される場合、それらを別のクラスに入れる価値があります。 各要求オブジェクトは、特定のビジネスルールに従って選択を行います。 たとえば、オブジェクト-完了した試用期間（ 明らかにCode Climateに慣れる試用期間を意味する）を見つけるための要求は次のようになります。

 class AbandonedTrialQuery def initialize(relation = Account.scoped) @relation = relation end def find_each(&block) @relation. where(plan: nil, invites_count: 0). find_each(&block) end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなクラスはバックグラウンドで使用して、手紙を送信できます。

 AbandonedTrialQuery.new.find_each do |account| account.send_offer_for_support end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ActiveRecord :: Relationクラスのメソッドを使用すると、構成を使用してクエリを結合するのに便利です。

 old_accounts = Account.where("created_at < ?", 1.month.ago) old_abandoned_trials = AbandonedTrialQuery.new(old_accounts)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのようなクラスをテストするときは、正しい順序で行のクエリ結果とデータベースからの選択を確認する必要があります。また、結合と追加クエリの存在を確認する必要があります（N + 1クエリなどのバグを回避するため）。

5.オブジェクトの表示

一部のメソッドがプレゼンテーションでのみ使用される場合、それらはモデルクラスに配置されません。 「音声駆動など、このアプリケーションの代替インターフェイスを実装する場合、この方法が必要ですか？」と自問してください。 そうでない場合は、ヘルパーまたは（さらに良い）ビューオブジェクトに転送する必要があります。



たとえば、Code Climateのドーナツグラフは、コードの状態のスナップショットに基づいてクラス評価を分類します。 これらのアクションは、次の形式のオブジェクトにカプセル化されます。

 class DonutChart def initialize(snapshot) @snapshot = snapshot end def cache_key @snapshot.id.to_s end def data # pull data from @snapshot and turn it into a JSON structure end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ビューとERB（またはHaml / Slim）パターンとの間に1対1の関係があることがよくあります。 これにより、 2ステップビューテンプレートを使用するというアイデアが得られましたが、Railsの定式化されたソリューションはまだありません。



注： 「プレゼンター」という用語はRubyコミュニティで受け入れられていますが、その曖昧さのために私はそれを避けています。 「プレゼンター」という用語は、私がオブジェクトと呼ぶもの、つまりフォームを記述するためにジェイ・フィールズによって提案されました 。 さらに、Railsでは「ビュー」という用語を使用して、一般に「テンプレート」と呼ばれるものを説明しています。 あいまいさを避けるため、ビューオブジェクトを「ビューモデル」と呼ぶことがあります。

6.ルールオブジェクトの選択（ポリシーオブジェクト）

複雑な読み取り操作には、個別のオブジェクトが必要な場合があります。 そのような場合、ポリシーオブジェクトを使用します。 これにより、たとえば、ユーザーのアクティビティをチェックするなど、モデルからサイドロジックを削除できます。

 class ActiveUserPolicy def initialize(user) @user = user end def active? @user.email_confirmed? && @user.last_login_at > 14.days.ago end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなオブジェクトは、ユーザーの電子メールが検証されたかどうか、およびユーザーが過去2週間にアプリケーションを使用したかどうかをチェックする1つのビジネスルールをカプセル化します。 ルールオブジェクトを使用して、複数のビジネスルールをグループ化することもできます。たとえば、ユーザーがアクセスできるデータを決定するAuthorizerオブジェクトなどです。



ルールオブジェクトはサービスオブジェクトに似ていますが、書き込み操作には「サービスオブジェクト」という用語を使用し、読み取り操作には「オブジェクトルール」という用語を使用します。 クエリオブジェクトにも似ていますが、クエリオブジェクトはSQLクエリを実行して結果を返すためにのみ使用され、ルールオブジェクトは既にメモリにロードされているドメインモデルで動作します。

7.デコレーターの強調表示

デコレータを使用すると、既存の操作で機能を構築できるため、コールバックに効果が似ています。 コールバックロジックを1回使用する場合、またはモデルに含めるのに多くの責任が伴う場合は、デコレーターを使用すると便利です。



ブログ投稿にコメントを作成すると、Facebookの壁にコメントが作成される場合がありますが、これは、このロジックがCommentクラスに含まれている必要があるという意味ではありません。 低速で脆弱なテスト、または無関係なテストでの奇妙な副作用は、コールバックにあまりにも多くのロジックを入れている兆候です。



Facebookコメントのコメントロジックをデコレータに配置する方法は次のとおりです。

 class FacebookCommentNotifier def initialize(comment) @comment = comment end def save @comment.save && post_to_wall end private def post_to_wall Facebook.post(title: @comment.title, user: @comment.author) end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コントローラーは次のようになります。

 class CommentsController < ApplicationController def create @comment = FacebookCommentNotifier.new(Comment.new(params[:comment])) if @comment.save redirect_to blog_path, notice: "Your comment was posted." else render "new" end end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デコレータは、既存のオブジェクトの機能を拡張するため、オブジェクト-サービスとは異なります。 ラップ後、デコレータオブジェクトは通常のCommentオブジェクトと同じ方法で使用されます。 Ruby標準ライブラリは、メタプログラミングを使用してデコレータの作成を簡素化するツールのセットを提供します。

おわりに

Railsアプリケーションでも、モデルの複雑さを制御する多くの機能があります。 いずれもフレームワークの原則に違反する必要はありません。



ActiveRecordは優れたライブラリですが、それだけに依存していると失敗することもあります。 ライブラリまたはフレームワークによってすべての問題を解決できるわけではありません。 モデルをデータベースとの相互作用のロジックのみに制限してください。 提示された手法を使用すると、モデルのロジックを配布し、その結果、保守しやすいアプリケーションを取得できます。



説明されているテンプレートのほとんどは非常にシンプルであり、これらのオブジェクトは単なるOld Old Ruby Object（PORO）であり、RailsでOOPアプローチを使用することの便利さを完全に示していることにお気づきでしょう。