Basic Ruby on Rails Design Patterns

Not only as programmers, but in day-to-day life, we encounter some problems. Every person has similar difficulties, and our society has found universal ways, patterns, to solve that problems. As programmers we also have problems, which can be solved by patterns. Our beloved Wikipedia says:

And I must say I love that definition. There is nothing more to explain.

I’ve chosen two design patterns I found the most common in Rails world - service and decorator. Main reason why they are so common is that they help keep models slim and DRY through moving great part of logic into other parts of application. And of course slim models are good models, so better learn those two design patterns!

Service

Service is by far my most used design pattern in Rails applications. The idea of this design pattern is very easy - if certain part of business logic doesn't really fit into model or controller, it may be good idea to put it into service. You can then use your service in multiple places, like models, controllers, jobs etc, keeping you application clean and DRY.

Default Rails app structure doesn't have folder where we can put our services. So we have to make one! Create services folder inside your app directory.

1app/
2  controllers/
3  ...
4    services/
5    base_service.rb
6    single_service.rb
7    some_group_of_services/
8      first_service.rb
9      second_service.rb

Now, when we have a place to store our servies, let's define base service, so that we are sure every service uses the same interface to communicate with the rest of the application.

1class BaseService
2  private_class_method :new
3
4  def self.call(*args)
5    new(*args).call
6  end
7end

That's it! Only one method, nothing more. Now, let's jump to the actual service.

1class YourService < BaseService
2
3  def initialize(first_variable, second_variable)
4    self.first_variable = first_variable
5    self.second_variable = second_variable
6  end
7
8  def call
9    # method body
10  end
11
12  private
13
14  attr_accessor :first_variable, second_variable
15end

Methods initialize and call are a must-have. If call method would be too long or complicated, it's best to create additional methods in private section. That's because only call method should be available outside of the service.

Decorator

In OOP, decorator gives us ability to extend particular object's behavior by equipping it with some additional methods. In Rails ecosystem I've usually seen this design pattern being used with draper gem.

Draper is useful when we have methods in models, which are used only in views. Using decorator design pattern means putting in them every bit of logic which is used only in views. So, if in User model we have method full_name, e.g.

1def full_name
2  "#{first_name} #{last_name}"
3end

We should move it into UserDecorator.

1class UserDecorator < Draper::Decorator
2  delegate_all
3
4  def full_name
5    "#{object.first_name} #{object.last_name}"
6  end
7end

Great thing is that not every user object in views will have that method, we have to decorate that object before sending it to the view, simply using user.decorate. So in controller we have to use:

1def show
2  @user = User.find(params[:id]).decorate
3end

And then, we can use this code in our views:

1<%= @user.full_name %>