ActiveSupports #descendantsメソッド：詳細

includeの違いを知っておくのは良いことですが およびprepend モジュールの場合、より現実的な例が、どちらを選択するかを示すのに役立つと思います。このようなモジュールの私の主なユースケースは、Railsエンジンを使用する場合です。

おそらく最も人気のあるRailsエンジンの1つはdeviseです。使用されているパスワードダイジェストアルゴリズムを変更したいとしますが、最初に、簡単な免責事項：

私が日常的にモジュールを使用しているのは、デフォルトのビジネスロジックを保持するRailsエンジンの動作をカスタマイズすることです。 制御するコードの動作をオーバーライドします 。もちろん、Rubyのどの部分にも同じ方法を適用できますが、 外部コードへの変更は変更と互換性がない可能性があるため、制御していないコード（他の人が管理しているgemなど）をオーバーライドすることはお勧めしません。

Deviseのパスワードダイジェストは、ここでDevise ::Models ::DatabaseAuthenticatableモジュールで行われます：

  def password_digest(password)
    Devise::Encryptor.digest(self.class, password)
  end

  # and also in the password check:
  def valid_password?(password)
    Devise::Encryptor.compare(self.class, encrypted_password, password)
  end

Deviseでは、独自のDevise::Encryptable::Encryptorsを作成することにより、ここで使用されているアルゴリズムをカスタマイズできます。 、これは正しい方法です。ただし、デモンストレーションの目的で、モジュールを使用します。

# app/models/password_digest_module
module PasswordDigestModule
  def password_digest(password)
    # Devise's default bcrypt is better for passwords,
    # using sha1 here just for demonstration
    Digest::SHA1.hexdigest(password)
  end

  def valid_password?(password)
    Devise.secure_compare(password_digest(password), self.encrypted_password)
  end
end

begin
  User.include(PasswordDigestModule)
# Pro-tip - because we are calling User here, ActiveRecord will
# try to read from the database when this class is loaded.
# This can cause commands like `rails db:create` to fail.
rescue ActiveRecord::NoDatabaseError, ActiveRecord::StatementInvalid
end

このモジュールをロードするには、Rails.application.eager_load!を呼び出す必要があります。 開発中、またはRails初期化子を追加してファイルをロードします。テストすることで、期待どおりに機能することがわかります。

> User.create!(email: "[email protected]", name: "Test", password: "TestPassword")
=> #<User id: 1, name: "Test", created_at: "2021-05-01 02:08:29", updated_at: "2021-05-01 02:08:29", posts_count: nil, email: "[email protected]">
> User.first.valid_password?("TestPassword")
=> true
> User.first.encrypted_password
=> "4203189099774a965101b90b74f1d842fc80bf91"

この例では、両方のinclude およびprepend 同じ結果になりますが、複雑さを追加しましょう。ユーザーモデルが独自のpassword_saltを実装している場合はどうなりますか メソッドですが、モジュールメソッドでオーバーライドします：

class User < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable
  has_many :posts

  def password_salt
    # Terrible way to create a password salt,
    # purely for demonstration purposes
    Base64.encode64(email)[0..-4]
  end
end

次に、独自のpassword_saltを使用するようにモジュールを更新します パスワードダイジェストを作成するときの方法：

  def password_digest(password)
    # Devise's default bcrypt is better for passwords,
    # using sha1 here just for demonstration
    Digest::SHA1.hexdigest(password + "." + password_salt)
  end

  def password_salt
    # an even worse way of generating a password salt
    "salt"
  end

さて、include およびprepend どちらを使用するかによって、どのpassword_saltが決まるため、動作が異なります。 Rubyが実行するメソッド。 prependを使用 、モジュールが優先され、次のようになります：

> User.last.password_digest("test")
=> "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3.salt"

includeを使用するようにモジュールを変更する 代わりに、Userクラスの実装が優先されることを意味します：

> User.last.password_digest("test")
=> "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3.dHdvQHRlc3QuY2"

通常、私はprependに手を伸ばします まず、モジュールを作成するときに、サブクラスのように扱いやすく、モジュール内のメソッドがクラスのバージョンをオーバーライドすると想定しているためです。明らかに、これは常に望ましいとは限りません。そのため、Rubyはincludeも提供します。 オプション。

class Class
  def descendants
    ObjectSpace.each_object(singleton_class).reject do |k|
      k.singleton_class? || k == self
    end
  end
end

# Ensure all models are loaded (should not be necessary in production)
Rails.application.load! if Rails.env.development?

ApplicationRecord.descendants.each do |model_class|
  # in the real world you'd want to send this off to background job(s)
  model_class.all.each do |record|
    if !record.valid?
      HoneyBadger.notify("Invalid #{model.name} found with ID: #{record.id}")
    end
  end
end