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.

app/
  controllers/
  ...
    services/
    base_service.rb
    single_service.rb
    some_group_of_services/
      first_service.rb
      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.

class BaseService
  private_class_method :new

  def self.call(*args)
    new(*args).call
  end
end

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

class YourService < BaseService

  def initialize(first_variable, second_variable)
    self.first_variable = first_variable
    self.second_variable = second_variable
  end

  def call
    # method body
  end

  private

  attr_accessor :first_variable, second_variable
end

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.

def full_name
  "#{first_name} #{last_name}"
end

We should move it into UserDecorator.

class UserDecorator < Draper::Decorator
  delegate_all

  def full_name
    "#{object.first_name} #{object.last_name}"
  end
end

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:

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

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

<%= @user.full_name %>

That’s all?

Of course not, you silly! The world of design patterns is a lot lot bigger than that. Not every of them would be applicable in RoR application, though. Or that particular problem you have. But still, it's very good to know some design patterns, even their main ideas. Because maybe one day, you'll have some problem and it can be solved with design pattern you know or at least heard of. Or maybe you will develop your own design pattern, that will be described in books? ;)