ltk/post.md

## post.md

      
    Raw
  

              post.md
            
          
    Slimming Down Your Models and Controllers with Concerns, Service Objects, and Tableless Models.

The Single Responsibility Principle


“A class should have one, and only one, reason to change.” - Uncle Bob

The single responsibility principle asserts that every class should have exactly one responsibility. In other words, each class should be concerned about one unique nugget of functionality, whether it be User, Post or InvitesController. The objects instantiated by these classes should be concerned with sending and responding to messages pertaining to their responsibility and nothing more.

“Fat models, thin controllers”

This is a common Rails mantra that a lot of tutorials, and thus a lot of beginners, follow when building their next application. While fat models are a little better than fat controllers, they still suffer from the same fundamental issues: when any one of the object's many responsibilities change, the object itself must change, resulting in those changes propagating throughout the app. Suddenly a minor tweak to a model broke half of your tests!
Benefits of following the single responsibility principle include (but are not limited to):

DRYer code: when every bit of functionality has been encapsulated into its own object, you find yourself repeating code a lot less.
Change is easy: cohesive, loosely coupled objects embrace change since they don’t know or care about anything else. Changes to User don’t impact Post at all since Post doesn’t even know that User exists.
Focused unit tests: instead of orchestrating a twisting web of dependencies just to setup your tests, objects with a single responsibility can easily be unit tested, taking advantage of doubles, mocks, and stubs to prevent your tests from breaking nearly as often.

No object should be omnipotent, including models and controllers. Just because a vanilla Rails 4 app directory contains models, views, controllers, and helpers does not mean you are restricted to those four domains.
There are dozens of design patterns out there to address the single responsibility principle in Rails. I'm going to talk about the few that I explored this summer.
Encapsulating model roles with concerns

Imagine you're building a simple online news site similar to Reddit or Hacker News. The main interaction a user will have with the app is submitting and voting on posts.
class Post < ActiveRecord::Base
  validates :title, :content, presence: true

  has_many :votes
  has_many :comments

  def vote!
    votes.create
  end
end

class Comment < ActiveRecord::Base
  validates :content, presence: :true

  belongs_to :post
end

class Vote < ActiveRecord::Base
  belongs_to :post
end
So far so good.
Now imagine that you want users to be able to vote on both posts and comments. You decided to implement a basic polymorphic association and end up with this:
class Post < ActiveRecord::Base
  validates :title, :content, presence: true

  has_many :votes, as: :votable
  has_many :comments

  def vote!
    votes.create
  end
end

class Comment < ActiveRecord::Base
  validates :content, presence: :true

  has_many   :votes, as: :votable
  belongs_to :post

  def vote!
    votes.create
  end
end

class Vote < ActiveRecord::Base
  belongs_to :votable, polymorphic: true
end
Uh oh. You already have some duplicated code with #vote!. To make matters worse you now want to have both upvotes and downvotes.
class Vote < ActiveRecord::Base
  enum type: [:upvote, :downvote]

  validates :type, presence: true

  belongs_to :votable, polymorphic: true
end
Vote's API has changed, as .new and .create now require a type argument. In the small case of just posts and comments, this is not too big of a change. But what happens if you have 10 models that can be voted on? 100?
Enter ActiveModel::Concern
module Votable
  extend ActiveModel::Concern

  included do
    has_many :votes, as: :votable
  end

  def upvote!
    votes.create(type: :upvote)
  end

  def downvote!
    votes.create(type: :downvote)
  end
end

class Post < ActiveRecord::Base
  include Votable

  validates :title, :content, presence: true

  has_many :comments
end

class Comment < ActiveRecord::Base
  include Votable

  validates :content, presence: :true

  belongs_to :post
end
Concerns are essentially modules that allow you to encapsulate model roles into separate files to DRY up your code. In our example, Post and Comment both fulfill the role of votable, so they include the Votable concern to access that shared behavior. Concerns are great at organizing the various roles played by your models. However, concerns are not the solution to a model with too many responsibilities.
Below is an example of a concern that still breaks the single-responsibility principle.
module Mailable
  extend ActiveModel::Conern

  def send_password_reset_email
    UserMailer.password_reset(self).deliver_now
  end

  def send_confirmation_email
    UserMailer.confirmation(self).deliver_now
  end
end
This problem is not something concerns are good at solving. A User model should not know about UserMailer. While the actual user.rb file does not contain any reference to UserMailer, the User class does.
Concerns are a great tool for sharing behavior between models, but must be used responsibly and with a clear intent.
Reducing controller complexity with Service objects

On the topic of emails, lets take a look at controllers. Imagine we want users to be able to invite their friends by submitting a list of emails. Whenever an email is invited, a new Invite object is created to keep track of who has already been invited. Any invalid emails are rendered in the flash with an error message.
class InvitesController < ApplicationController
  def new
  end

  def create
    emails.each do |email|
      if Invite.new(email).save
        UserMailer.invite(email).deliver_now
      else
        invalid_emails << email
      end
    end
    unless invalid_emails.empty?
      flash[:danger] = "The following emails were not invited: #{invalid_emails}"
    end
    redirect_to :new
  end

  private

  def emails
    params.require(:invite).permit(:emails)[:emails]
  end

  def invalid_emails
    @invalid_emails ||= []
  end
end
What exactly is wrong with this code you might ask? The single responsibility of a controller is to accept HTTP requests and respond with data. In the above code, sending an invite to a list of emails is an example of business logic that does not belong in the controller. Unit testing sending invites is impossible because this feature is so tightly coupled to InvitesController. You might consider putting this logic into the Invite model, but that's not much better. What would happen if you wanted similar behavior in another part of the application that was not tied to any particular model or controller?
Fortunately there is a solution! Many times specific business logic like sending emails in bulk can be encapsulated into a plain old ruby object (affectionately known as POROs). These objects, often referred to as Service or Interaction objects, accept input, perform work, and return a result. For complex interactions that involve creating and destroying multiple records of different models, service objects are a great way to encapsulate that responsibility out of the models, controllers, views, and helpers framework Rails provides by default.
class BulkInviter
  attr_reader :invalid_emails

  def initialize(emails)
    @emails = emails
    @invalid_emails = []
  end

  def perform
    emails.each do |email|
      if Invite.new(email).save
        UserMailer.invite(email).deliver_now
      else
        invalid_emails << email
      end
    end
  end
end

class InvitesController < ApplicationController
  def new
  end

  def create
    inviter = BulkInviter.new(emails)
    inviter.perform
    unless inviter.invalid_emails.empty?
      flash[:danger] = "The following emails were not invited: #{inviter.invalid_emails}"
    end
    redirect_to :new
  end

  private

  def emails
    params.require(:invite).permit(:emails)[:emails]
  end

  def invalid_emails
    @invalid_emails ||= []
  end
end
In this example the responsibility of sending emails in bulk has been moved out of the controller and into a service object called BulkInviter. InvitesController does not know or care how exactly BulkInviter accomplishes this; all it does is ask BulkInviter to perform its job. While much better than the fat controller version, there is still room for improvement. Notice how InvitesController still needs to know that BulkInviter has a list of invalid emails? That additional dependency further couples InvitesController to BulkInviter.
One solution is to wrap all output from service objects into a Response object.
class Response
  attr_reader :data, :message

  def initialize(data, message)
    @data    = data
    @message = message
  end

  def success?
    raise NotImplementedError
  end
end

class Success < Response
  def success?
    true
  end
end

class Error < Response
  def success?
    false
  end
end

class BulkInviter

  def initialize(emails)
    @emails = emails
  end

  def perform
    emails.each do |email|
      if Invite.new(email).save
        UserMailer.invite(email).deliver_now
      else
        invalid_emails << email
      end
    end
    if invalid_emails.empty?
      Success.new(emails, "Emails invited!")
    else
      Error.new(invalid_emails, "The following emails are invalid: #{invalid_emails}")
    end
  end
end

class InvitesController < ApplicationController
  def new
  end

  def create
    inviter = BulkInviter.new(emails)
    response = inviter.perform
    if response.success?
      flash[:success] = response.message
    else
      flash[:danger] = response.message
    end
    redirect_to :new
  end

  private

  def emails
    params.require(:invite).permit(:emails)[:emails]
  end
end
Now InvitesController is truly ignorant of how BulkInviter works; all it does is ask for BulkInviter to do some work and sends the response off to the view.
Service objects are a breeze to unit test, easy to change, and can be reused as your app grows. However, like any design pattern, service objects have an associated cost. Abusing the service object design pattern often results in tightly coupled objects that feel more like shifting methods around and less like following the single responsibility principle. More objects also means more complexity and finding the exact location of a particular feature involves digging through a services directory.
The biggest challenge I faced when designing service objects is defining an intuitive API that easily communicates the responsibility of the object. One approach is to treat these objects like procs or lambdas, implementing a #call or #perform method that performs work. While this is great for standardizing the interface across service objects, it heavily relies on descriptive class names to communicate the object's responsibility.
One idea I've used to further communicate the purpose of service objects is to namespacing them into their specific domain:
Invites::BulkInviter
Comments::Creator
Votes::Aggregator
The exact implementation of these service objects is largely style based and depends on the complexity of your business logic.
Taking advantage of Active Record Model

The last topic I want to cover is the idea of tableless models. Starting in Rails 4, you can include ActiveModel::Model to allow an object to interface with Action Pack, gaining the full interface that Active Record models enjoy. Objects that include ActiveModel::Model are not persisted in the database, but can be instantiated with attribute assignment, validated with built in validations, and have forms generated with form helpers, and much more!
When would you make a tableless model? Let's look at an example!
Imagine we are building an online password strength checker. There are many characteristics that a good password should have, such as an 8 character minimum and a combination of uppercase and lowercase letters. Since these passwords have no use elsewhere in our app, we don't want to persist them in the database.
Our first attempt might involve some kind of service object.
class PasswordStrengthController < ApplicationController
  def new
  end

  def create
    checker = PasswordChecker.new(string: params[:string])
    if checker.perform
      flash.now[:success] = "That is a strong password."
    else
      flash.now[:danger] = "That is a weak password."
    end
    render :new
  end
end

class PasswordChecker
  attr_reader :string

  def initialize(string:)
    @string = string
  end

  def perform
    length?(8)             &&
    contains_nonword_char? &&
    contains_uppercase?    &&
    contains_lowercase?    &&
    contains_digits?
  end

  private

  def length?(n)
    password.length >= n
  end

  def contains_nonword_char
    password.match(/.*\W.*/)
  end

  def contains_uppercase
    password.match(/.*[A-Z].*/)
  end

  def contains_lowercase
    password.match(/.*[a-z].*/)
  end

  def contains_digits
    password.match(/.*[0-9].*/)
  end
end
While this works, something feels off about our new PasswordChecker service object. It's not interacting with any models and it does not change any states. The service object API is awkward as it is not clear if #perform is a query or a command. If we take a step back and think about what exactly this service object's responsibility is, we soon arrive at validating the strength of a password. In other words, PasswordChecker contains and validates a set of data, much like Active Record models do.
This is a great case for tableless models!
class PasswordCheck
  include ActiveModel::Model

  attr_accessor :string

  validates :string, length: { minimum: 8 }
  validates :string, format: { with: /.*\W.*/,    message: "must contain nonword chars"     }
  validates :string, format: { with: /.*[A-Z].*/, message: "must contain uppercase letters" }
  validates :string, format: { with: /.*[a-z].*/, message: "must contain lowercase letters" }
  validates :string, format: { with: /.*[0-9].*/, message: "must contain digits"            }
end

class PasswordStrengthController < ApplicationController
  def new
    @password = PasswordCheck.new
  end

  def create
    @password = PasswordCheck.new(string: params[:string])
    if @password.valid?
      flash.now[:success] = "That is a strong password."
    else
      flash.now[:danger] = "That is a weak password."
    end
    render :new
  end
end
Not only do we get the power of built in validations, it becomes much easier to render error messages and generate the form for submitting a new password.


Concerns, service objects, and tableless models are all excellent ways to fight growing pains experienced when building a Rails application. It is important not to force design patterns, but to discover them while building your application. In many scenarios, DRYing up model roles with Concerns, creating a service object layer between your models and controllers, or encapsulating temporary data into tableless models makes a lot of sense. Other times it smells a lot like premature optimization and is not the best approach.
As with everything programming, the best way to learn is to get your hands dirty!
Further Reading


Code Conerns in Rails 4 Models
7 Patterns to Refactor Fat ActiveRecord Models
Service objects in Rails help you design clean and maintainable code.
Using Services to Keep Your Rails Controllers Clean and DRY
Practical Object Oriented Design in Ruby