What is the Processor Model Design Pattern in Rails?

Software design pattern is used in software designing as a solution to multiple occurring problems. It is not some code that could be fed into the machine, rather it is a description template for designs that needs to be adopted and why. These design patterns are regarded as best practices to be adopted by a programmer to solve common problems while designing an application.

There are many types of design patterns including Service Design Pattern, Observer Design Pattern, Decorator Design Pattern, Strategy Design Pattern, etc.

Processor Model Design Pattern

As projects become more complex, so do the models within them. One of the major issues in the class ActiveRecord is that it mixes the methods of two major roles: persistence and business logic. As any project reaches the age of maturity, a clear distinction between these roles becomes more visible, and it becomes necessary to break them into two distinct domain objects. The Processor Model Design adopts this idea by providing a pattern to adopt these necessary changes.

How to use it

Creating a Processor Object

A processor object is created in order to manipulate data from other objects. It can be an implementation of the Facade Pattern or even a kind of Decorator Pattern.

Code for a processor:

class MyProcessor
  def initialize(a, b)
    @a = a
    @b = b
  end
end

You can store your processor objects into app/models, but if you’d like a little more separation, it’s common to create app/lib and store the objects in there.

Practical Techniques

A processor object with primarily Ruby attributes and methods such as:

1. attr_reader. short for “Attribute Reader”, creates an instance variable and accessor method for you. For example, a class Chocolate will create a class and any instance will have access to attributes title, cost, and Is_expired. They can be accessed using commands such as Chocolate.title or Chocolate.cost:

class Chocolate
  attr_reader :title, :cost, :expired

end

2. delegate. The Law of Demeter generally says that we can talk to an object, but we shouldn’t talk directly to the object’s children.

class Chocolate
  attr_reader :title, :cost, :expired
  delegate :Name, :Company to: :title
  delegate :price to: :cost
  delegate :manufacturing_date, :expiry_date, to: :expired
end

Now, these children can be accessed from anywhere using commands such as Chocolate.Name, Chocolate.expiry_date, etc.