この記事は ex-crowdworks Advent Calendar 2024の18日目の記事です。
はじめに
今年、株式会社クラウドワークスを退職した@nisyuuです。今年、食べて正解だった海鮮丼はじもの亭の海鮮丼（華）です。
エンジニアとしてクラウドワークステック（旧クラウドテック）というフリーランスと企業をマッチングするエージェントサービスを開発していました。
Policyオブジェクトパターンは、ソフトウェア設計において権限管理やアクセス制御を明確にするためのデザインパターンです。
特に、Webアプリケーションでは、ユーザーが特定の操作を実行できるかどうかを判定する場面で頻繁に利用されます。
本記事では、Policyオブジェクトパターンの基本的な概念と利点・欠点、さらにRuby on Railsでの実装例について解説します。
Policyオブジェクトパターンとは
Policyオブジェクトパターンは、アプリケーション内のビジネスルールを1つのクラスにカプセル化して管理する設計手法です。このパターンは以下のような特徴があります：
- 役割の分離: 権限管理のロジックをモデルやコントローラーから切り離して、専用のクラスにまとめます
- 単一責任原則（SRP）: 各Policyオブジェクトは特定のリソースと操作に対するルールのみを担当します
- テストの容易さ: 権限ロジックを独立したクラスとして実装するため、テストがしやすくなります
基本的な構成
Policyオブジェクトは、通常以下のように構成されます：
-
対象リソース: 許可または拒否を判断するリソース（例：
Postモデル） -
メソッド: 各操作（例：
create?、update?）の許可/拒否を判定するメソッド - コンテキスト: 現在のユーザーやその他の関連情報（例：ログインユーザー）
Policyオブジェクトパターンのメリットとデメリット
メリット
- コードの可読性向上: 権限ロジックが明確に分離されるため、コードベースが読みやすくなります
- 再利用性の向上: Policyオブジェクトを異なるコントローラーやモデル間で再利用可能
- テストの容易化: テストが個別のクラス単位で実施でき、ユニットテストが簡単
- 保守性の向上: 権限ロジックが1か所に集約されているため、変更が容易
デメリット
- クラスの増加: 小規模なアプリケーションでは、ファイルやクラスの数が増えすぎて煩雑になる可能性がある
- 学習コスト: 初心者にとって、別途Policyオブジェクトを作成する設計思想に慣れる必要がある
- パフォーマンス: 設計の複雑さにより、パフォーマンスに若干の影響が出ることもある
Ruby on Railsでの実装例
RailsでのPolicyオブジェクトパターンの実装には、PunditというGemが広く利用されています。以下は、Punditを使った基本的な実装例です。
Gemのインストール
まず、PunditをGemfileに追加します。
# Gemfile
gem 'pundit'
インストール後、以下のコマンドでセットアップを行います：
bundle install
rails g pundit:install
Policyクラスの作成
例えば、Postモデルに対するPolicyオブジェクトを作成します。
rails g pundit:policy post
以下のようなファイルが生成されます：
# app/policies/post_policy.rb
class PostPolicy < ApplicationPolicy
def show?
true # 全てのユーザーが閲覧可能
end
def update?
user.admin? || record.user_id == user.id # 管理者または投稿者本人のみ更新可能
end
def destroy?
user.admin? # 管理者のみ削除可能
end
end
コントローラーでの利用
PostPolicyを利用してアクセス制御を行います。
# app/controllers/posts_controller.rb
class PostsController < ApplicationController
before_action :authenticate_user!
before_action :set_post, only: [:show, :update, :destroy]
def show
authorize @post # Punditのauthorizeメソッドを使用
end
def update
authorize @post
if @post.update(post_params)
redirect_to @post, notice: '投稿を更新しました。'
else
render :edit
end
end
def destroy
authorize @post
@post.destroy
redirect_to posts_path, notice: '投稿を削除しました。'
end
private
def set_post
@post = Post.find(params[:id])
end
def post_params
params.require(:post).permit(:title, :content)
end
end
Policy Specの作成
PolicyオブジェクトのテストはRSpecを使うと簡単です。
# spec/policies/post_policy_spec.rb
require 'rails_helper'
describe PostPolicy do
subject { described_class.new(user, post) }
let(:user) { User.create(role: 'admin') }
let(:post) { Post.create(user: user) }
context '管理者ユーザーの場合' do
it { is_expected.to permit_action(:update) }
it { is_expected.to permit_action(:destroy) }
end
context '通常ユーザーの場合' do
let(:user) { User.create(role: 'user') }
it { is_expected.to forbid_action(:destroy) }
end
end
おわりに
Policyオブジェクトパターンは、アプリケーションの権限管理を分離し、コードの保守性と再利用性を向上させるために有効です。
Railsでは、Punditのようなツールを利用することで、簡単かつ効率的に実装が可能です。
小規模なプロジェクトでは冗長に感じるかもしれませんが、中〜大規模なアプリケーションではそのメリットを感じられるでしょう。