如何重构Rails中的Pundit Policy以实现DRY原则？

首先说结论：当前写法是完全可行的——毕竟代码能正常运行，就像你提到的集成测试里的部分重复有时可接受。但从长期维护角度看，Policy和控制器里的重复代码确实值得重构，尤其是当你的权限逻辑变得复杂后，重复会导致修改时要改多处，容易出错。

一、控制器重复授权的优化 #

你在artists_controller.rb的多个动作里重复调用authorize @artist，可以通过before_action统一处理，前提是先确保@artist已经被初始化：

# artists_controller.rb
class ArtistsController < ApplicationController
  before_action :set_artist, only: [:show, :edit, :update, :destroy]
  # 统一授权需要@artist的动作
  before_action :authorize_artist, only: [:show, :edit, :update, :destroy]

  # ... 其他动作代码 ...

  private

  def set_artist
    @artist = Artist.find(params[:id])
  end

  def authorize_artist
    authorize @artist
  end
end

这样就不用在每个动作里单独写authorize @artist了，既简洁又统一。

二、ArtistPolicy 代码重复的重构 #

针对Policy里的重复逻辑，可以通过以下几种方式优化：

1. 提取通用判断到私有方法 #

如果多个权限方法都用到相同的判断逻辑（比如判断用户是否是管理员），可以把这段逻辑封装成私有方法，在各个权限方法里调用：

# artist_policy.rb
class ArtistPolicy < ApplicationPolicy
  def show?
    admin_or_authorized?
  end

  def edit?
    admin_or_authorized?
  end

  def update?
    admin_or_authorized?
  end

  def destroy?
    admin_or_authorized?
  end

  def create?
    admin?
  end

  private

  # 封装重复的判断逻辑
  def admin_or_authorized?
    # 这里替换成你实际的权限判断逻辑
    admin?
  end
end

2. 使用 alias_method 复用权限逻辑 #

如果多个动作的权限完全相同，可以用alias_method直接复用方法，避免重复代码：

# artist_policy.rb
class ArtistPolicy < ApplicationPolicy
  def show?
    admin?
  end

  # 让edit?、update?、destroy?复用show?的逻辑
  alias_method :edit?, :show?
  alias_method :update?, :show?
  alias_method :destroy?, :show?

  def create?
    admin?
  end
end

3. 复用 ApplicationPolicy 的通用逻辑 #

你的application_policy.rb应该作为所有Policy的父类，把全局通用的权限逻辑（比如登录判断、管理员判断）放在这里，让子Policy继承复用，而不是在每个子Policy里重复写。比如：

# application_policy.rb
class ApplicationPolicy
  attr_reader :user, :record

  def initialize(user, record)
    @user = user
    @record = record
    raise Pundit::NotAuthorizedError, "Must be logged in" unless user
  end

  # ... 其他默认方法 ...

  private

  # 全局通用的管理员判断
  def admin?
    user.admin?
  end
end

这样ArtistPolicy里直接调用admin?即可，不用重复实现。

三、Pundit 政策的标准结构 #

Pundit推荐的标准结构是采用父类抽象通用逻辑，子类实现模型特有权限的模式：

• ApplicationPolicy：定义所有Policy共用的逻辑（比如用户登录校验、管理员判断、基础权限默认值）
• 每个模型的Policy（比如ArtistPolicy）继承ApplicationPolicy，只实现该模型特有的权限规则，复用父类的通用方法
• 用私有方法封装模型特有的重复判断逻辑
• 对权限相同的动作使用alias_method减少冗余
• 控制器中尽量用before_action统一处理授权（注意资源初始化的顺序）

内容的提问来源于stack exchange，提问作者Lee McAlilly