You can’t just discover a pattern and copy this into your program like you can with ready-made functions or libraries. The pattern is not a single Code but a general notion for dealing with a given situation. You can use the pattern details to design a solution appropriate to your software’s circumstances.

Patterns and algorithms are sometimes misconstrued since both represent common solutions to well-known situations. A pattern is a much more elevated solution description than an algorithm. The code for the same pattern may differ when applied to two separate programs. On the one hand, a pattern is like a blueprint in that you can see the consequences and features. However, the Implementation is entirely up to you.

So, what exactly are Ruby Design Patterns? Let’s have a peek.

What Are The Design Patterns in Ruby?

Design Patterns are popular solutions to challenges in software design. They are like pre-made layouts that you can change in code to tackle a reoccurring design challenge. You cannot discover a pattern and replicate it in your application like you can with functions or libraries. A design pattern in Ruby is a general notion for tackling a specific problem rather than a specific piece of code. You can follow the pattern specifics and implement a solution appropriate to your program’s circumstances.

What Does The Pattern Consist Of?

Ruby design patterns are very carefully documented so they can be reproduced in various scenarios. The following are among the components always contained in a ruby design pattern.

• Intent: The pattern’s intent briefly outlines the problem and possible remedies.
• Motivation: Motivation clarifies the issue and aids in discovering patterns that allow for a solution.
• Structure: of classes depicts each Component of the design and how well they are connected.
• Code Example: It is amongst the most frequently used techniques, which helps to understand the design simpler.

Why Should I Learn Ruby Design Patterns?

Even if you’ve been a developer for several years, probably, you don’t know about every single pattern. You can still use them even if you haven’t spent time learning them. So, why should you invest time studying Ruby design patterns?

Design patterns are a collection of tried-and-true answers to typical program design difficulties. Knowing patterns is useful even if you never experience these challenges since it informs you how to tackle all kinds of problems using Object-oriented design concepts.

Ruby Design patterns provide a common language that your teammates and you may utilize to communicate more effectively. If you understand the pattern name, you don’t need to explain it. Now that you understand what Ruby design patterns are let’s look at the categories of design patterns in ruby.

Categories of Ruby Design Pattern

The intricacy, depth of detail, and applicable scalability to the overall built system differentiate design patterns. In 1994, four authors, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, wrote a book titled Design Patterns – Elements of Reusable Object-Oriented Software, which launched the Design Pattern concept in software development. This group of authors is known as the Gang of Four (GOF). According to these writers, design patterns are mostly based on the object-oriented design concepts listed below.

• Program to an interface, not an implementation
• Favor object composition over inheritance

The GoF design patterns are divided into three categories:

• Creational Patterns
• Structural Patterns
• Behavioral Patterns

Creational Patterns

These patterns provide an object creation mechanism that increases flexibility and reuse of existing code.

Behavioral Patterns

These Patterns handle good communication and responsibility assignment among objects.

Structural Pattern

To maintain these structures adaptable and effective, structural design patterns describe how to combine items and classes into a bigger structure.

Creational Patterns

There are 5 design patterns in the creational design patterns category. Let’s start with the first one, Abstract Factory.

Abstract Factory

Creating complete product families without identifying their concrete classes is a challenge that the creational design pattern known as Abstract Factory addresses. All different goods can be created using the interface defined, but the actual manufacturing of the products is left to the concrete factory classes. There is a certain product variety for each type of factory. Instead of producing goods by calling a constructor with the new operator, the client code instead invokes the creation methods of a factory object. All of the items produced by a factory will be compatible because each product variant corresponds to a certain factory.

Through their abstract interface, client code only interacts with factories and products. As a result, the client code can use every product created using a factory object. The client code is given a new concrete factory class that you created.

Why use Abstract Factory?

• The goods you purchase from a factory will be compatible so you can be certain of that.
• Be careful not to tightly couple client code with concrete items.
• Single-responsibility rule The code can be centralized and readily supported if the product generation code is extracted.
• You can offer new product variants using the open/closed paradigm without modifying the existing client code.

Also Read : 8 Spectacular Benefits of Using Ruby on Rails for Web Development

Code Example

# The Abstract Factory interface declares a set of methods that return different
# abstract products. These products are called a family and are related by a
# high-level theme or concept. Products of one family are usually able to
# collaborate among themselves. A family of products may have several variants,
# but the products of one variant are incompatible with products of another.
class AbstractFactory
  # @abstract
  def create_product_a
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  # @abstract
  def create_product_b
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

# Concrete Factories produce a family of products that belong to a single
# variant. The factory guarantees that resulting products are compatible. Note
# that signatures of the Concrete Factory's methods return an abstract product,
# while inside the method a concrete product is instantiated.
class ConcreteFactory1 

Builder Pattern

A creational design pattern called Builder enables the gradual development of complicated items. Unlike other creational designs, the Builder does not demand that products have a common interface. Because of this, different products can be produced using the same construction method.

Following the builder pattern, you should relocate the object building code from an object’s class into independent objects referred to as builders. The patterns break down the process of building an object into a series of steps. These operations are carried out on a builder object to generate an object. Not all steps need to be called, which is an essential point. You are limited to calling the steps required to produce a specific configuration of an object. Some construction processes may require distinct implementations when building alternative representations of the product.

Why Use Builder Pattern?

• Construction phases can be postponed or repeated recursively when developing things step-by-step.
• Build numerous product representations using the same construction code.
• Solitary-Responsibility Rule From The Product’s Business Logic, You Can Separate complicated building code.

Code Example

# The Builder interface specifies methods for creating the different parts of
# the Product objects.
class Builder
  # @abstract
  def produce_part_a
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  # @abstract
  def produce_part_b
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  # @abstract
  def produce_part_c
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

# The Concrete Builder classes follow the Builder interface and provide specific
# implementations of the building steps. Your program may have several
# variations of Builders, implemented differently.
class ConcreteBuilder1 

Factory Method

The factory method, also known as the Virtual Constructor, is a creational design pattern that solves the problem of creating product objects without specifying their concrete classes. The Factory Method defines a method that should be used to create objects instead of a direct constructor call (new operator). Subclasses can override this method to change the class of objects that will be created.

The factory method pattern suggests that you replace direct object construction calls with a special factory method. The objects are still created via the new operator, but it’s being called from within the factory method. Objects returned by a factory method are often referred to as products.

Why use the factory method?

• By doing this, you prevent a close relationship between both the Creator and the tangible output.
• Single-responsibility rule To make the program’s code easier to support, you can consolidate the code for product creation in one location.
• The Open/Closed Principle Without affecting the current client code, you can add new product categories to the program.

Code Example

# The Creator class declares the factory method that is supposed to return an
# object of a Product class. The Creator's subclasses usually provide the
# implementation of this method.
class Creator
  # Note that the Creator may also provide some default implementation of the
  # factory method.
  def factory_method
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  # Also note that, despite its name, the Creator's primary responsibility is
  # not creating products. Usually, it contains some core business logic that
  # relies on Product objects, returned by the factory method. Subclasses can
  # indirectly change that business logic by overriding the factory method and
  # returning a different type of product from it.
  def some_operation
    # Call the factory method to create a Product object.
    product = factory_method

    # Now, use the product.
    result = "Creator: The same creator's code has just worked with #{product.operation}"

    result
  end
end

# Concrete Creators override the factory method in order to change the resulting
# product's type.
class ConcreteCreator1 

Prototype

The Prototype, commonly called the Clone design pattern, is a creational pattern that enables you to duplicate existing objects without having your code depend on their classes. The actual items being duplicated are given control over the cloning process.

For all objects that support cloning, the pattern declares a common interface. This interface can copy an object without linking your program to the object’s class. Typically, such an interface has one clone method.

In all classes, the clone method is implemented relatively similarly. The method produces a new object of the current class while importing all field values from the old object. Since private fields of other objects that are members of the same class can typically be accessed by objects, you can even clone private fields in most programming languages.

Prototypes are items that allow for cloning. Clone your objects instead of subclassing them if they have dozens of fields and hundreds of possible configurations.

Why use Prototype?

• Objects can be copied apart from the concrete classes that make them up.
• Cloning pre-built prototypes allow you to do away with repetitive initialization code.
• You have more ease in producing complex objects.
• When working with configuration settings for complicated objects, inheritance is a substitute you can use.

Code Example

# The example class that has cloning ability. We'll see how the values of field
# with different types will be cloned.
class Prototype
  attr_accessor :primitive, :component, :circular_reference

  def initialize
    @primitive = nil
    @component = nil
    @circular_reference = nil
  end

  # @return [Prototype]
  def clone
    @component = deep_copy(@component)

    # Cloning an object that has a nested object with backreference requires
    # special treatment. After the cloning is completed, the nested object
    # should point to the cloned object, instead of the original object.
    @circular_reference = deep_copy(@circular_reference)
    @circular_reference.prototype = self
    deep_copy(self)
  end

  # deep_copy is the usual Marshalling hack to make a deep copy. But it's rather
  # slow and inefficient, therefore, in real applications, use a special gem
  private def deep_copy(object)
    Marshal.load(Marshal.dump(object))
  end
end

class ComponentWithBackReference
  attr_accessor :prototype

  # @param [Prototype] prototype
  def initialize(prototype)
    @prototype = prototype
  end
end

# The client code.
p1 = Prototype.new
p1.primitive = 245
p1.component = Time.now
p1.circular_reference = ComponentWithBackReference.new(p1)

p2 = p1.clone

if p1.primitive == p2.primitive
  puts 'Primitive field values have been carried over to a clone. Yay!'
else
  puts 'Primitive field values have not been copied. Booo!'
end

if p1.component.equal?(p2.component)
  puts 'Simple component has not been cloned. Booo!'
else
  puts 'Simple component has been cloned. Yay!'
end

if p1.circular_reference.equal?(p2.circular_reference)
  puts 'Component with back reference has not been cloned. Booo!'
else
  puts 'Component with back reference has been cloned. Yay!'
end

if p1.circular_reference.prototype.equal?(p2.circular_reference.prototype)
  print 'Component with back reference is linked to original object. Booo!'
else
  print 'Component with back reference is linked to the clone. Yay!'
end

Singleton

Singleton is a creational design pattern that ensures that only one object of its kind exists & provides a single point of access to it for any other code. Singleton has almost the same pros n cons are global variables. However, they break the modularity of your code.

Why use Singleton?

• You can be certain that there is just one instance of a class.
• In that instance, you obtain a global access point.
• Only when it is first requested is the singleton object initialized.

It is divided into Naïve Singleton & Thread-safe Singleton

Naïve Singleton

It’s pretty easy to implement a sloppy Singleton. You need to hide the constructor and implement a static creation method. The same class behaves incorrectly in a multithreaded environment. Multiple threads can call the creation method simultaneously and get several instances of the Singleton class. You can understand the concept better with the example below:

# The Singleton class defines the `instance` method that lets clients access the
# unique singleton instance.
class Singleton
  @instance = new

  private_class_method :new

  # The static method that controls the access to the singleton instance.
  #
  # This implementation let you subclass the Singleton class while keeping just
  # one instance of each subclass around.
  def self.instance
    @instance
  end

  # Finally, any singleton should define some business logic, which can be
  # executed on its instance.
  def some_business_logic
    # ...
  end
end

# The client code.

s1 = Singleton.instance
s2 = Singleton.instance

if s1.equal?(s2)
  print 'Singleton works, both variables contain the same instance.'
else
  print 'Singleton failed, variables contain different instances.'
end

Thread-safe Singleton

To fix the problem, you have to synchronize threads during the first creation of the Singleton object. You can understand this concept much better with the following example:

# The Singleton class defines the `intance` method that lets clients access the
# unique singleton instance.
class Singleton
  attr_reader :value

  @instance_mutex = Mutex.new

  private_class_method :new

  def initialize(value)
    @value = value
  end

  # The static method that controls the access to the singleton instance.
  #
  # This implementation let you subclass the Singleton class while keeping just
  # one instance of each subclass around.
  def self.instance(value)
    return @instance if @instance

    @instance_mutex.synchronize do
      @instance ||= new(value)
    end

    @instance
  end

  # Finally, any singleton should define some business logic, which can be
  # executed on its instance.
  def some_business_logic
    # ...
  end
end

# @param [String] value
def test_singleton(value)
  singleton = Singleton.instance(value)
  puts singleton.value
end

# The client code.

puts "If you see the same value, then singleton was reused (yay!)\n"\
     "If you see different values, then 2 singletons were created (booo!!)\n\n"\
     "RESULT:\n\n"

process1 = Thread.new { test_singleton('FOO') }
process2 = Thread.new { test_singleton('BAR') }
process1.join
process2.join

Structural Patterns

The Gangs of Four book on design patterns describes seven structural design patterns. With the Adapter, let’s begin.

Adapter

The adaptor sometimes referred to as Wrapper, is a structural design pattern that enables the cooperation of incompatible objects. You can design an adaptor, a unique object that changes one object’s interface so that another can comprehend it.

An adapter covers one of the objects to conceal the intricate conversion process behind the scenes. The wrapper object does not know the adaptor at all. An adaptor that translates all the data to imperial units like feet and miles can encase an object that functions in meters and kilometers, for instance.

The adaptor can assist items with distinct interfaces in cooperating and converting data into various formats. Here’s how it functions.

• The Adapter gets an interface compatible with one of the existing objects.
• Using this interface, the existing object can safely call the Adapter’s method.
• Upon receiving a call, the Adapter passes the request to the second object but in a format & other than what the second object expects.

Why use an Adapter?

• Single-responsibility rule The program’s main business logic can be separated from the code for the interface or data conversion.
• The Open/Closed Principle If you use the client interface to interact with the adapters, you can add new types of adapters to the application without affecting the code that already runs the clients.

Also Read : React With Ruby on Rails

Code Example

# The Target defines the domain-specific interface used by the client code.
class Target
  # @return [String]
  def request
    'Target: The default target\'s behavior.'
  end
end

# The Adaptee contains some useful behavior, but its interface is incompatible
# with the existing client code. The Adaptee needs some adaptation before the
# client code can use it.
class Adaptee
  # @return [String]
  def specific_request
    '.eetpadA eht fo roivaheb laicepS'
  end
end

# The Adapter makes the Adaptee's interface compatible with the Target's
# interface.
class Adapter 

Bridge

A structural design pattern called the bridge splits a large class or body of business logic into discrete class hierarchies that can be created separately. It enables the separation of a large class or group of related classes into two distinct hierarchies, Abstraction and Implementation, which can be developed separately from one another.

Abstraction is a high-level control layer for something and is also referred to as an interface. This layer does not intend to perform any actual work by itself. The implementation layer should be assigned the task (also called the platform). You should know that we are not discussing interfaces or abstract classes from your programming language. The two are not equivalent.

Why use Bridge Pattern?

• You can develop classes and applications that are platform-independent.
• The high-level abstractions used by the client programs are. The platform specifics aren’t revealed to it.
• The Open/Closed Principle New implementations and abstractions may be introduced without relation to one another.
• Single-responsibility rule When implementing, you can concentrate on platform specifics, while Abstraction focuses on high-level logic.

Code Example

# The Abstraction defines the interface for the "control" part of the two class
# hierarchies. It maintains a reference to an object of the Implementation
# hierarchy and delegates all of the real work to this object.
class Abstraction
  # @param [Implementation] implementation
  def initialize(implementation)
    @implementation = implementation
  end

  # @return [String]
  def operation
    "Abstraction: Base operation with:\n"\
    "#{@implementation.operation_implementation}"
  end
end

# You can extend the Abstraction without changing the Implementation classes.
class ExtendedAbstraction 

Composite

A structural design pattern called Composite, called Object Tree enables you to assemble items into tree structures and then treat those hierarchies as when they were individual objects.

Using the composite structural design pattern, things can be combined into a tree-like structure and used as if they were a single entity. It became a fairly well-liked mechanism for running procedures.

Why use Composite?

• You may work with complex tree structures more conveniently by utilizing polymorphism and recursion to your advantage.
• The application of Closed & Open principles will allow for introducing a new element type while maintaining the functionality of the existing code already present in the object tree.

Code Example

# The base Component class declares common operations for both simple and
# complex objects of a composition.
class Component
  # @return [Component]
  def parent
    @parent
  end

  # Optionally, the base Component can declare an interface for setting and
  # accessing a parent of the component in a tree structure. It can also provide
  # some default implementation for these methods.
  def parent=(parent)
    @parent = parent
  end

  # In some cases, it would be beneficial to define the child-management
  # operations right in the base Component class. This way, you won't need to
  # expose any concrete component classes to the client code, even during the
  # object tree assembly. The downside is that these methods will be empty for
  # the leaf-level components.
  def add(component)
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  # @abstract
  #
  # @param [Component] component
  def remove(component)
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end

  # You can provide a method that lets the client code figure out whether a
  # component can bear children.
  def composite?
    false
  end

  # The base Component may implement some default behavior or leave it to
  # concrete classes (by declaring the method containing the behavior as
  # "abstract").
  def operation
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

# The Leaf class represents the end objects of a composition. A leaf can't have
# any children.
#
# Usually, it's the Leaf objects that do the actual work, whereas Composite
# objects only delegate to their sub-components.
class Leaf 

Decorator

Using a structural design pattern called Decorator, you may give objects different behaviors by enclosing them in special wrapper objects that also contain the behaviors. Since both target objects and decorators have the same interface, you can wrap things multiple times using decorators. The final product will exhibit all of wapper’s stacking behavior. It is rather common in ruby code, particularly in work that deals with streams.

The alternate term for the decorator pattern, Wrapper, perfectly captures the pattern’s central concept. A wrapper is a linkable object that can link to a target object. It delegates to it all requests it receives and has the same set of methods as the target. While doing something either before or after passing the request to the destination, the Wrapper can change the outcome.

Why use a Decorator?

• Without creating a new subclass, you can change how an object behaves.
• At runtime, you can change an object’s responsibility.
• You can combine several behaviors by encasing a given object with a number of decorators.
• Using the single responsibility concept, you may break up a monolithic class that implements a variety of possible behavioral variants into smaller classes.

Code Example

# decorators.
class Component
  # @return [String]
  def operation
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"
  end
end

# Concrete Components provide default implementations of the operations. There
# might be several variations of these classes.
class ConcreteComponent 

Façade