Design Patterns in Ruby

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" - Christopher Alexander

"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".

A Design Pattern is a template to solve a problem which can be used in many different situations. It names, abstracts and identifies the key aspects of a common design structure that makes it useful for creating a reusable object - oriented design. Design Patterns in Object - Oriented Languages help show the relationship between the different classes and objects in the program. Design Patterns are tools for building software.

Overview

Design Patterns capture solutions that have evolved over time as developers strive for greater flexibility in their software, and they document the solutions in a way which facilitates their reuse in other, possibly unrelated systems.

The different types of design patterns can be categorized and listed as below:

Creational Pattern, which help create the objects for the user, instead of having the user to instantiate the object.

Factory Pattern, which allows a class to defer instantiation to subclasses.
Abstract Factory Pattern, which provides an interface for creating related or dependent objects without specifying the objects' concrete classes.
Builder Pattern, which separates the construction of a complex object from its representation so that the same construction process can create different representation.
Prototype Pattern, which specifies the kind of object to create using a prototypical instance, and creates new objects by cloning this prototype.
Singleton Pattern, Ensure that only one instance of a class is created and Provide a global access point to the object.

Structural Pattern, which employ interfaces to achieve inheritance to enable objects to obtain new functionality.

Adapter Design Pattern, which enables classes with incompatible interfaces to work together.

Behavioral Pattern, which are concerned with communication between objects.

Command Design Pattern, which enables to pass around the code that needs to be executed later.
Algorithm Strategy Pattern, which helps choose an algorithm to fulfill a task based on some "parameter" of the situation.

There are lot of patterns in each of the categories. There's no mention of them. If the idea is that we these are the patterns available out of the box in ruby, it should be explicitly mentioned here.

Creational Pattern

Singleton Pattern

The first design pattern one should know about is the Singleton patterns. It is basically the case, where the Class can instantiate only one object, which is globally available.

Need better definition.

Below is an illustration of the general Syntax of Singleton Design Pattern in Ruby:

require 'singleton'
class Example
    include Singleton
    ...
end

It could be noticed that one must 'require' a module called 'singleton' and include the module within the class. This adds the singleton flavour to your class. Now to test if it can create multiple instances, we can inquisitively try this,

 raisesError = Example.new
 ruby-1.9.2-p290 :026 > raisesError = Example.new
 NoMethodError: private method `new' called for Example:Class

We will soon find out we are greeted with the NoMethodError( Some kind of an error is expected ). So how do we use a singleton pattern? We create an instance of it using the keyword 'instance'

'What is meant by Some kind of error is expected? Content here is good, will need to rephrase.'

a = Example.instance
=> #<Example:0x9361cb8> 
b = Example.instance
=> #<Example:0x9361cb8>

The above illustrates how to create the instance of the Singleton class. It also illustrates another point. Even though two 'instances' have supposedly been created, both of them happen to contain reference to the same object. This further proves that only one object can be created for a Singleton.

Rephrase again. Not formal enough

That was the Ruby's default way to create singletons. Singletons can be created manually without using the 'singleton' module.

class Single_ton
def initialize
   puts "Initialised"
end

@@instance = Single_ton.new
 
def self.instance
   return @@instance
end
 
def print_something
  puts "This prints something"
end
  
private_class_method :new
end

The above snippet is actually a singleton class. A cursory reading shall read the logic behind singleton-ing the class. An object to the same class has been created as a class variable. a ".instance" method is defined. One more thing to notice is that, "new" method is made 'private'. This makes sure that one cannot create anymore objects of the singleton.

Single_ton.instance
=> #<Single_ton:0x94483d4> 
Single_ton.instance.print_something
This prints something

The above snippet shows that our class 'behaves' like a singleton. We have a '.instance' method defined and it works. The method could be accessed by accessing the lone object inside the class.

The Singleton Pattern is useful in situations where serialization is desirable, example logging, communication and database access etc. In these cases, only a single instance of the class is created which accesses and modifies the methods of the class. This ensures safety and also make the single instance responsible for the class.
Here is more to read on Singleton patterns.

Feel like there's some flab in the Singleton section that we can cut. Also could think of adding subsections for Default Implemenation, Custom Implementation, Uses etc.

Structural Patterns

Adapter Pattern

An Adapter pattern, also known as the Wrapper Pattern enables classes with incompatible interfaces to work together, by providing the users with its interface. This is achieved by:
In other words, when we want our new class to support a pre-existing feature, instead of modifying our new class, we can 'wrap' a similar feature in our new class to behave like the older class so that the pre-existing feature is supported.

Some cleaning up to do

Consider a software company located in United Kingdom. Lets assume they have these classes in their system.

class Bicycle
  def rideBiCycle
    puts 'Iam riding a bicycle'
    end
  end

The following class has a method which calls the method 'rideBiCycle' in the passed argument.

class Tester
  def displayRide(object)
    object.rideBiCycle
    end
  end

Now, If an American company buys this British company and tries to reuse the code. It has the following class already to its use.

class Bike
  def rideBike
    puts 'I am riding a bike'
   end
 end

But, the problem is that, Bike doesn't have the function 'rideBiCycle', so it cannot use the Tester class directly. If that tester class sits in a very important part of the code, there is a problem. Now the way out is to create a 'adapter' which assimilates a 'bike' object. This adapter is actually a 'Bike' which can mimic itself like a 'Bicycle' by supporting the method 'rideBiCycle'.
Now to understand it. We will create a bunch of instances.

cycle = Bicycle.new
cycle.rideBiCycle
Iam riding a bicycle

test = Tester.new
test.displayRide(cycle)

bike = Bike.new
bike.rideBike
I am riding a bike

So far, the respective objects are working well when used in isolation. But when we have to do this,

 test.displayRide(bike)
 NoMethodError: undefined method `rideBiCycle' for #<Bike:0x94b4494>

We encounter an error which is pretty obvious because rideBiCycle is not defined in Bike. Now let us define the adapter,

class BikeAdapter
  def initialize(bike)
    @bikeObject = bike
    end
  def rideBiCycle
    @bikeObject.rideBike
  end                                                                                                                 
end

Now we can try the failed method call like this,

adapter = BikeAdapter.new(bike)
test.displayRide(adapter)
Iam riding a bike

Voila! We have succesfully 'adapted' Bike class to behave like 'Bicycle'.
This one is a good read on Adapter patterns and also contains links to other articles about Adapter Pattern.

I found the example thoroughly confusing. Let me know what you think.

Behavioral Patterns

Closures and Patterns

Patterns can be implemented using Closures. A Closure can be described as a block of code ith the properties mentioned below:

The block of code can be passed around like a value.
Any procedure or method that has the value can execute it.
A Closure can refer to the variables from the context in which it was created.

Why does he/she start off with Closures and Patterns? Since there's a whole section on it elsewhere, makes no sense to give such a hasty explanation that doesn't make stuff clear at all. What is meant by Patterns can be implemented using closures? Can all patterns be implemented using closures?

The Command Design Pattern and Strategy Design Patterns are examples of this.

Command Pattern

The design patterns we saw above deal with classes and work around the way classes and objects are manipulated, interpreted, created etc. Actually, the adapter pattern bases its necessity on the need for 'code reuse'. But, it can only implement code reuse at a class or method level. What if we need a more finer to do it.For example, Sometimes one might need to store bunch of code to be used by a peer or himself at a later point. This bunch of code is not associated with any class, or any method.

Command Patterns lends itself to our use at this point. With command pattern it is possible to store a piece of code or a set of commands to be executed at a later stage. And of course, this is implemented with the use of procs in Ruby.

This is how command pattern is usually implemented. We have a class which holds the commands as a Proc Object. And whenever it is to be called, 'call' is used to execute that proc.

class Command
  def initialize(input)
    @local_proc = input 
  end

  def return_proc
   @local_proc
  end
end

Now we have a class that stores a command. Now let us create a 'command'.

myProc = proc{ puts 8 }

Now we have a proc object that we want to use.

obj = Command.new(myProc)
obj.return_proc.call
8

Then we create an object storing myProc inside it. Then we use the object to return the proc and use 'call' on it to execute it. One could also create an array of commands by simply creating an array of Command objects and storing the proc in them.

One important use of the Command Pattern is to enable the client undo what he has already done, or redo what has been undone by the user. This is done by maintaining a history of the commands executed. As and when the user makes changes, the system creates command after command, executing each command immediately to effect the change. Every undo - able command holds two methods - the execute and the unexecute method. The commands are stored in a list and when the user decides to undo a change, the last command on the list is executed to undo the change. The changes can be undone, by going back the history of commands. The redo is done in the similar way where the the commands are re-executed beginning from the last change that what undone to reapply the changes undone. A simple example of the undo - redo use of a Command Pattern is a Calculator with many undo - redo options.

This is not much use without a code example

Algorithm Strategy Pattern

The Strategy Pattern helps choose an algorithm to accomplish a task based on some "parameters" of the situation. Also known as the Policy Pattern, it enables selection of algorithms at runtime. This pattern allows the algorithm to vary irresepctive of the user that uses it.

The strategy pattern "defines a family of algorithms, encapsulates each one, and makes them interchangeable".

Consider as an example, a class that that converts among different types of file formats like jpeg, jif, png etc. We can write a case statement to choose what algorithm has to be employed for each type of format. Another example could be performing validation on incoming data. Here we can select a validation algorithm based on the type and source of data.

A Strategy Pattern is best implemented using Proc Objects. Below is an example of the Strategy Pattern which deals with areas of geometric shapes:

class findArea
    attr_accessor :strategy
    def calArea(x,y)
         strategy.call(*args)
    end
    def area_square … end
    def area_rect … end
end

Here, we have a class findArea, which calculates the area of the given geometric shape by invoking the methods area_square or area_rect based upon whether the given figure is a square or rectangle.

sides = findArea.new
if x == y
      puts "The given object is a square"
      sides.strategy = findArea.method(:area_square)
else
      puts "The given object is a rectangle"
      sides.strategy = findArea.method(:area_rect)
end
sides.calArea(x,y)

Here, the path or strategy chosen is based on an if condition involving the values of x and y which are not known until runtime. Therefore, the algorithm that will be made use of to calculate the area, is decided at run time. The strategy that will be chosen depends on many factors which change dynamically.

Differences between Command and Strategy Pattern

A Command Pattern encapsulates a single action. A command object has a single method with a generic signature associated with it.
A Strategy Pattern, enables us to customize an algorithm, deciding which algorithm has to be made use of depending on a number of dynamically changing factors. A given strategy has many methods associated with it.

Comparsion of the different Design Patterns

Comparison Factor	Singleton Pattern	Adapter Pattern	Command Pattern	Strategy Pattern
Intent	Ensure only one object of a class is instantiated, provide a global point of access to that object	Convert the interface of a class into one that the client expects	Encapsulate a request in an object and allow the parameterization of clients with different requests	Encapsulate a set of algorithms and use them interchangeably.
Advantages	Helps achieve serialization and is useful in scenarios of logging, communication and lazy instantiations	Enables classes to communicate which otherwise would not be able to due to incompatible interfaces.	Addition of new functionality is fairly simple as it just calls for encapsulating the functionality into the Command Object.	Large conditional statements are eliminated which makes it easy to keep track of the different behaviors which are now in separate classes.
Disadvantages	Brings in the concept of global state, making unit testing difficult. Also reduces the scope of parallelism within the program.	When using Object Adapters, all the code for delegating all the necessary requests to the Adaptee has to be written.	The increase in the number of Command Classes, clutters up the design.	The increase in the number of objects, and all the algorithms use the same interface.

We could also add a section on drawbacks of design patterns. I found a link on that.

CSC/ECE 517 Fall 2012/ch1b 1w42 js

Design Patterns in Ruby

Contents

Overview

Creational Pattern

Singleton Pattern

Structural Patterns

Adapter Pattern

Behavioral Patterns

Closures and Patterns

Command Pattern

Algorithm Strategy Pattern

Differences between Command and Strategy Pattern

Comparsion of the different Design Patterns

See Also

References

Navigation menu

CSC/ECE 517 Fall 2012/ch1b 1w42 js

Design Patterns in Ruby

Overview

Creational Pattern

Singleton Pattern

Structural Patterns

Adapter Pattern

Behavioral Patterns

Closures and Patterns

Command Pattern

Algorithm Strategy Pattern

Differences between Command and Strategy Pattern

Comparsion of the different Design Patterns

See Also

References

Navigation menu

Search