The main principle of software development is to keep the code DRY (Don’t Repeat Yourself) to reduce the reduction in the code. So, Ruby On Rails follows some design patterns to achieve the DRY principle.

Our beloved Wikipedia says, that

“software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can > be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design > > patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.”

https://en.wikipedia.org/wiki/Software_design_pattern

Though we can use models, helpers, and concerns to make the code dry, if the code complexity is higher or we are using external API, in that case, we use rails Design Patterns.

Here is the ruby on rails design patterns:

(1) Service Objects
(2) View Objects
(3) Query Objects
(4) Decorators
(5) Form Objects
(6) Value Objects
(7) Policy Objects

Let’s Discuss the all above-mentioned ruby design patterns one by one with examples.

(1) Service Objects

What is a Service Object?

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

A Service Object is PORO – Plain Old Ruby Object, which is meant to encapsulate business logic and complex calculations into manageable classes and methods.

When to use service objects?

  1. When we need to perform complex calculations or business logic, for, e.g. if we need to calculate employee’s salaries based on their attendance.
  2. When we need to implement any other API, for, eg. we need to implement payment gateway such as Stripe.
  3. When we want to import CSV that contains the bulk of data.
  4. When we need to clear garbage/unused/old data from the database in an efficient manner that it won’t affect the existing data.

Have a look at PaymentsController; here, you can see that the controller is too skinny. Payment service has solved the problem of too much code inside the controller and made the controller skinny and readable.

Class PaymentsController < ApplicationController
  def create
    PaymentService.new(params).call
    redirect_to payments_path
    rescue Stripe::CardError => e
    flash[:error] = e.message
    redirect_to new_payment_path
  end
end

Now create payment_service.rb inside your_project/app/services folder.

class PaymentService
  def initialize(options = {})
    options.each-pair do |key, value|
      instance_variable_set("@#{key}", value)
    end
  end

  def call
    Syripe::Charge.create(charge_attributes)
  end
  private

  attr_render :email, :source, :amount, :description

  def amount 
	@amount.to_i * 100
  end

  def customer
    @customer ||=
Stripe::Customer.create(customer_attributes)
  end

  def customer_attributes
    {
     email: email,
     source: source
     }
  end

 def charge_attributes
  {
   customer: customer.id,
   amount: amount,
   description: description
  }
 end

end


(2) View Objects Click For view Object
(3) Query Objects
(4) Decorators
(5) Form Objects
(6) Value Objects
(7) Policy Objects

Thanks For Reading ..

Always keep your code skinny and dry. Happy Coding ..

Leave a Reply

Your email address will not be published. Required fields are marked *