How to implement Policy Object pattern in Ruby on Rails?

In simple terms, Policy Object allows us to encapsulate complex business rules and is used to replace complex conditions.

Why do we need it and what problems can this pattern solve?

Sometimes we have complex business rules that are used directly in the business logic. For example, the following code can be used many times in different controllers and service objects:

def show
  user = User.first

  if user.status == 'active' && user.approved_at.present?
    render json: user
  else
    render status: :forbidden
  end
end

Problems:

• NOT possible to test separately from the controller.
• NOT DRY
• Violates single-responsibility principle
• NOT clear, hard to read and understand what's going on.

So what can we do to fix it?

• We can move this logic to the model level.
• We can create a Policy Object class and move the logic there.

Let's take a look at these options one by one.

Model methods

Adding new model methods is the easiest option, we just need to extend our model in the following way:

# frozen_string_literal: true

class User < ApplicationRecord

  def active?
    status == 'active' && approved_at.present?
  end

  def cancelled?
    status == 'cancelled' && cancelled_at.present?
  end

end

user = User.last
user.active?
user.cancelled?

Why do we need other options if the model methods solve our problems?

There're 2 problems:

• The first one is that we violate the Single responsibility and the open-closed SOLID principles ('a class should basically serve one purpose' and 'a class/object should be open for extension, but closed for modification'). The model becomes too FAT and responsible for too many things. In real projects, we'll end up with a hundred different methods and lines of codes, because one such method can contain 10 private methods under the hood. You can probably imagine how difficult it would be to read, modify and maintain this class.
• The second problem here is potential additional arguments. Right now we only use the user object, but in the future the business rules may require other objects as well, so it won't be easy to maintain such code.

That's why it would be nice to have the same interface, but move all the methods into a separate class.

How can we do that?

Meet Policy Object

We're going to implement Policy Object via plain Ruby object because it's the clearest and the most straightforward solution.

Let's take a look at the following example.

# app/units/policies/user.rb

# frozen_string_literal: true

module Policies
  class User

    def initialize(user)
      @user = user
    end

    def active?
      user.status == 'active' && user.approved_at.present?
    end

    def cancelled?
      user.status == 'cancelled' && user.cancelled_at.present?
    end

    private

    attr_reader :user

  end
end

user_policy = Policies::User.new(User.last)
user_policy.active?
user_policy.cancelled?

We just encapsulate our rules inside a separated class and that's it. The following code stick to SOLID principle and can take as many arguments as we want. Pretty simple, isn't it? Let's take a look at other possible names that are commonly used inside policy objects to get a wider picture:

def apply?; end

def allowed?; end

def permitted?; end

def eligible?; end

def satisfy?; end

def excluded?; end

def locked?; end

def approved?; end

def not_approved?; end

def required?; end

# etc...

Have you figured out what all these Policy Object methods have in common yet? Here they are:

• Policy object methods always return boolean values (true or false)
• Policy object methods always end with a ?
• Policy objects must not have any side-effects

So the final solution may look as follows:

def show
  user = User.first

  if Policies::User.new(user).active?
    render json: user
  else
    render status: :forbidden
  end
end

Conclusion

• Thanks to Policy Object we can separate logic better and test our code more easily.
• Policy Object is DRY and reusable
• Policy Object allows us to avoid FAT model and stick to SOLID principles
• Policy Object reduces "Cognitive Overhead", so the code is much easier to understand.