class Song < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  # ...
end

この時点ではかなり便利でナイーブですよね？モデルの重量が少し減り、トラッシングは、ソングモデルだけでなく、他のモデル全体で再利用できるようになりました。まあ、物事は複雑になる可能性があります。調べてみましょう。

ミックスインの典型的な例

懸念事項の詳細に着手する前に、それらについて別の説明を追加しましょう。 include SomeModule が表示されたら、 またはextendAnotherModule 、これらはミックスインと呼ばれます。ミックスインは、他のクラスに追加できるコードのセットです。そして、Rubyのドキュメントからわかるように、モジュールはメソッドと定数のコレクションです。したがって、ここで行っているのは、メソッドと定数を含むモジュールをさまざまなクラスに含めて、それらを使用できるようにすることです。

これは、 Trashableで行ったこととまったく同じです。 懸念。モデルオブジェクトをモジュールにトラッシュすることに関する一般的なロジックを抽出しました。このモジュールは、後で他の場所に含めることができます。つまり、ミックスイン はRubyやRailsだけでなく使用されているデザインパターンですが、どこで使用されても、人々はそれが好きで良いと思うか、嫌いで簡単に制御不能になると思います。

これをよりよく理解するために、それらを使用することの長所と短所をいくつか見ていきます。うまくいけば、これを行うことで、懸念事項をいつ使用するか、使用するかどうかを理解することができます。

すべて持っています

Trashable のように、懸念事項を抽出することにした場合 懸念されるのは、 Trashableのすべての機能にアクセスできるようになったことです。 含まれています。これは大きな力をもたらしますが、リチャードシュニーマンがこのトピックに関するブログ投稿で述べたように、「大きな力には複雑なコードを作成する優れた能力があります」。彼は、信頼できるコードを複雑にすることを意味しました。 あなたの懸念にそこにいること。

Trashableを見てみましょう もう一度：

module Trashable
  extend ActiveSupport::Concern
 
  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end
 
  def trash
    update_attribute :trashed, true
  end
end

懸念の論理は、がゴミ箱に入れられたという事実に依存しています 懸念事項が含まれる場合は常にフィールドが存在します。右？大したことではありません、これは私たちが結局望んでいることです。しかし、私が見ているのは、人々がモデルから他のものを懸念に引き込みたくなるということです。これがどのように発生するかを描くために、 Songを想像してみましょう。 モデルには別のメソッドfeatured_authorsがあります ：

class Song < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  def featured_authors
    authors.where(featured: true)
  end
 
  # ...
end
 
class Album < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  def featured_authors
    authors.where(featured: true)
  end
 
  # ...
end

説明をわかりやすくするために、 Albumを追加しました Trashableも含むモデル 。それでは、曲とアルバムの注目の作者がゴミ箱に入れられたときに通知したいとしましょう。人々はこの論理を次のように懸念の中に入れたくなるでしょう：

module Trashable
  extend ActiveSupport::Concern
 
  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end
 
  def trash
    update_attribute :trashed, true
 
    notify(featured_authors)
  end
 
  def notify(authors)
    # ...
  end
end

ここで、物事は少し複雑になり始めています。 Songモデルの外部にトラッシングロジックがあるため、 Trashableに通知を入れたくなるかもしれません。 懸念。そこでは、何か「間違った」ことが起こります。 features_authors Songから取得されます モデル。 OK、このパスプルリクエストのレビューとCIチェックを考えてみましょう。

次に、数か月後に、開発者が features_authorsの提示方法を変更する必要があるという新しい要件が設定されます。 歌のために。たとえば、新しい要件では、ヨーロッパの注目の著者のみを表示する必要があります。当然、開発者は、注目の著者が定義されている場所を見つけて編集します。

class Song < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  def featured_authors
    authors.where(featured: true).where(region: 'Europe')
  end
 
  # ...
end
 
class Album < ApplicationRecord
  include Trashable
 
  has_many :authors
 
  # ...
end

これは、作者をどこに見せてもうまく機能しますが、本番環境にデプロイした後は、世界の他の地域の人々は彼らの曲について通知されなくなります。このような間違いは、懸念事項を使用するときに簡単に発生します。上記の例は単純で人工的なものですが、「野生の」ものは非常に扱いにくい場合があります。

ここで危険なのは、懸念事項（mixin）が、含まれるモデルについて多くのことを知っていることです。これは、いわゆる循環依存です。 。 歌 およびアルバム Trashableに依存 ゴミ箱の場合、ゴミ箱 features_authorsは両方に依存します 意味。 がゴミ箱に入れられたという事実についても同じことが言えます Trashable を使用するには、両方のモデルにフィールドが存在する必要があります 作業に関する懸念。

これが、無関心クラブが反対する可能性がある理由であり、親関心クラブは賛成です。 最初の Trashableのバージョン これは、コードベースで使用するものです。通知を改善して2番目のバージョンを作成する方法を見てみましょう。

どこから来たのか

Trashableを振り返って 通知することで、私たちはそれについて何かをしなければなりません。懸念を使用するときに起こる別のことは、私たちが物事を過度に乾燥させる傾向があるということです。これ）：

module Authorable
  has_many :authors
 
  def featured_authors
    authors.where(featured: true)
  end
end

次に、 Song およびアルバム 次のようになります：

class Song < ApplicationRecord
  include Trashable
  include Authorable
 
  # ...
end
 
class Album < ApplicationRecord
  include Trashable
  include Authorable
 
  # ...
end

すべてを枯渇させましたが、ヨーロッパの注目作家の要件が満たされていません。さらに悪いことに、 Trashable 懸念事項とモデルはAuthorableに依存します 。なんてこったい？少し前に懸念事項を扱っていたときの私の質問です。メソッドがどこから来ているのかを追跡するのは難しいです。

これらすべてに対する私の解決策は、 features_authorsを維持することです。 可能な限りモデルに近づけます。 通知 メソッドはすべきではありません Trashableの一部になる まったく心配。特にモデルが異なるサブグループに通知する傾向がある場合は、各モデルが独自にそれを処理する必要があります。苦痛を軽減する方法を見てみましょう：

 
# Concerns
module Trashable
  extend ActiveSupport::Concern
 
  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end
 
  def trash
    update_attribute :trashed, true
  end
end
 
module Authorable
  has_many :authors
 
  # Other useful methods that relate to authors across models.
  # If there are none, ditch the concern.
end
 
# Models
class Song < ApplicationRecord
  include Trashable
  include Authorable
 
  def featured_authors
    authors.where(featured: true).where(region: 'Europe')
  end
 
  # ...
end
 
class Album < ApplicationRecord
  include Trashable
  include Authorable
 
  def featured_authors
    authors.where(featured: true)
  end
 
  # ...
end

  # ...
 
  include Subscribable # Depends on Readable
  include Eventable    # Depends on Recordables
 
  # ...