Nine Mohs

Just before a month ago I was sweating out, playing away with my small little Ruby programs which were surely not pieces of code you’ll want to read and learn with. Now just after my fifteen day brawl with the Design Patterns, I find myself a totally revamped programmer.
This is my new article series which would cover a few of the popular programming Design Patterns in software engineering devised by the GoF. I would be starting off with some basic Design Patterns and then move onto Ruby specific patterns based upon the book “Design Patterns In Ruby” by Russ Olsen.

The Design Patterns that’ll be explained are :

1. The Template Method (explained here)
2. The Factory Method

(They will be updated as the series expands)
You can Subscribe to my Blog Feeds for constant updates on the articles or you can follow me on www.twitter.com/kitallis
This is the base article for the series and you can always look back at this as an archive for others.

Prerequisites would be, a knowledge of Ruby’s Object Oriented features and a belief that this would actually help you get better.
These articles would follow a simple pattern of explaining the design pattern, disadvantages without it and improving with it. If you don’t quite get what I’m talking about, you might want to take a look at this.

The Template Method Pattern

When is it needed?
The Design patterns are a way of solving a problem in a particular way and is in no way related to reducing the complexity of the algorithm.
The basic problem on which this DP is implemented upon is a varying piece of code mixed in with the part that remains static. So we would be separating the code that stays the same (probably the algorithm) with the piece of code that is dynamic (probably the processing data).

How can we do it?
By separating and encapsulating the common entities into a subclass and the changing entities/behaviour into derived classes and thereby allowing the common behaviour to not repeat itself.
More specifically, building an abstract base class with a skeletal method (template method) that’d control the part that needs to vary by making calls to the Abstract Method whose actual control is further provided by the subclasses.
Even more strictly, this is an actual application of the Template Method Pattern in the ControlTier project which defines an application installation procedure
(other details are unnecessary here)

(Courtesy : ControlTier Wiki)

The Template Methods residing in the Abstract class are ‘driving’ certain Operations and the subclasses are actually implementing those Operations. So here, InstallPackage is the Template Method which defines all usable methods and zip is the concrete subclass which calls methods it requires.

So, the quick advantages we get are :

1. We can expand to more subclasses even if they require a varying algorithm for the methods defined

2. The algorithm is separated from the static definitions and initialisations

This is my dummy code for the pattern

class Package  # this is the abstract base class
 
  def initialize
  #
  end
 
  def InstallPackage  # this is the template method
 
  create
  installDependencies
  prepare
  get
  extract
  finish
 
  end
 
  def installDependencies
  #
  end
 
  def prepare
  #
  end
 
  def get
  #
  end
 
  def extract
  #
  end
 
  def finish
  #
  end
 
  end
 
class Zip < Package  # this is the concrete subclass
 
  def create
  #
  end
 
  def extract
  #
  end
 
end

And it might be called this way

z = Zip.new
 
z.InstallPackage # calling the template method from the subclass

GOF describes a Hook Method
These are basically just virtual methods which may or may not have code inside them in base classes.
They are a way of telling the concrete subclasses that “either use the default implementation in the abstract class or override it for some varying algorithm and do something different”

Implementations without this pattern could be

class Package
 
  def initialize
  end
 
  def get_method(type)
  end 
 
  if type == "Zip" 
 
  # create algorithm
  # extract algorithm
 
  elsif #some other type
 
  end
 
end

which could be amazingly hard to expand for large pieces of code.
I’m obviously not that experienced a programmer to write hugely scalable projects but I find it a good habit to adopt patterns even while writing smaller snippets.