The Factory Method Pattern

I have to this say this, but Wikipedia has a pretty good explanation and a Ruby implementation for this Creational Pattern, so I’d be focusing mainly upon the general idea of why this pattern is similar to the Template Method pattern and explain some of its defined variants.

What is it?

It is a Creational design pattern : defining how created objects should be mechanised as per the pattern as chances are there might be design problems with bad object control.

When is it needed?

It’s all about picking the right class. It’s pretty much like the Template Method pattern. In the Template Method pattern there was a generic portion which was stored in a base class and the other fill-in-the blanks were controlled by the subclasses and the Template method drove certain methods so that they needn’t be explicitly called. Here, with the Factory Method those subclasses determine what objects to be created. So the Factory Method is for creating objects as Template Method was for driving an algorithm.

How is it done?

Here’s my dummy implementation for the Factory Method pattern.

module Factory
  def draw
     raise NotImplementedError, "You need to call this method, brotha"
  end
end

class Circle
 include Factory
 def draw
   # Clear Screen
   # Draw Circle
 end
end

class Square
 include Factory
   def draw
     # Clear Screen
     # Draw Square
   end
end

class Tetrahedron
  include Factory
  def draw
    # Clear Screen
    # Draw Square
  end
end

class RandomShape
  include Factory
    def draw
      # Clear Screen
      # Draw any shape apart from the above three
    end
end

class CreateShape
  def self.CallShapes(shape)
    case(shape)
      when "Circle"
        Circle.new
      when "Square"
        Square.new
      when "Tetrahedron"
        Tetrahedron.new
    else
      RandomShape.new
    end
  end
end

More precisely, the Shape module is for defining the Draw method which raises a predefined NotImplementedError exception object. Circle, Square and Tetrahedron are the subclasses which call the Shape module and are called by the Factory Method – CallShapes for creating objects out of them to be selected as per the user call.

This pattern is used when a class (theCreator) does not know beforehand all the subclasses that it will create. Instead, each subclass (the Concrete Creator) is left with the responsibility of creating the actual object instances.
The example shown here is specifically a Parametrized Factory Method, that takes in certain parameters from the user and creates objects accordingly.

Abstract Factory Method can pretty much be understood by this UML diagram

(Courtesy : Design patterns in Ruby )

The basic idea behind Abstract Factory Methods are to form a group of factories that are compatible with each other. According to the diagram, there are Two Factories encapsulated by one single Abstract factory and each concrete factory produces its set of compatible products. And that’s pretty much what Abstract Factory Methods are.

Taking an example from the Book, the ActiveRecord library uses a form of this kind of pattern.
ActiveRecord has an adapter class for each different kind of database that it uses like MySQL, Oracle. To set up the connection the user name, password, and a string containing the name of the adapter that ActiveRecord uses is supplied. So we enter ‘mysql’ if we want to talk to a MySQL database and so on. To accomplish this a Base class is present that has no adapter related code.
But there are Subclasses that modifying the Base code, that is, each adapter adds a method that creates its specific type of connection to
the Base class.

class Base
# Lots of non-adapter-related code removed...
end

class Base
  def self.mysql_connection(config)
 # Create and return a new MySQL connection, using
 # the user name, password, etc. stored in the
 # config hash...
  end
end

class Base
  def self.oracle_connection(config)
 # Create a new Oracle connection...
  end
end

If a structured object creation method like the Factory Method in a class is not implemented, we might end up creating methods for each new object we want to create.

References

[1] Wikipedia

[2] Programmers Heaven

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.

TCPSocket and TCPServer classes in the Ruby Standard Library are braindead-simple to implement.
The Ruby Programming Language shows how (comments are self-explanatory) :

# A Multithreaded Server
 
require 'socket'
 
# This method expects a socket connected to a client.
# It reads lines from the client, reverses them and sends them back.
# Multiple threads may run this method at the same time.
 
def handle_client(c)
 while true
   input = c.gets.chop                 # Read a line of input from the client
   break if !input                     # Exit if no more input
   break if input == "quit"            # or if the client asks to.
   c.puts(input.reverse)               # Otherwise, respond to client.
   c.flush                             # Force our output out
 end
 c.close                               # Close the client socket
end
 
server = TCPServer.open(2000) # Listen on port 2000
 
while true                             # Servers loop forever
 client = server.accept                # Wait for a client to connect
 Thread.start(client) do |c|           # Start a new thread
   handle_client(c)                    # And handle the client on that thread
 end
end

Gserver, one of the better standard libraries in Ruby.

More flexible than the socket library, it can be used to implement application level servers, it has a few useful predefined methods like the number of connections, event logging and handles all threading problems by itself, that means multiple users can connect on a single server at once (Asynchronous Socket programming -  which is, where many clients connect to a single server and send input for processing concurrently, the server then handles all the connected clients asynchronously and process the data as and whenever it is available from any of them.)

This little toy Chat Program reads a single input from the client, shuffles it and sends it back.

CLIENT

require 'socket'                           # Sockets are in standard library
 
sock = TCPSocket.open("localhost",1234)    # Socket to listen on port 1234
 
  l = STDIN.gets                           # Get a single input from console
  sock.puts(l)                             # Send input to the server
  sock.flush                               # Force input
  line = sock.readpartial(4096)            # Read server's response
  puts line                                # Display the response to the user
 
sock.close                                 # Close the socket

SERVER

require 'gserver'
 
# Algorithm to shuffle a string
 
def shuffle(str)
 
lenth = str.length
 
index = (lenth-1)
 
  while(index >= 0) do
 
   random_number = rand(lenth)
 
   str[random_number], str[index] = str[index], str[random_number]
 
   index = index - 1
 
  end
 
str
end
 
class Server < GServer                  # Server class derived from GServer super class
  def initialize(port=1234, *args)      # to use the initialize function
      super(port, *args)
  end
 
  def serve(io)                         # Serve method handles connections
 
      input = io.gets.chop!             # Get input from client console
      io.puts(shuffle(input))           # Return the shuffled input onto the client console
      puts input                        # Print the client message 
 
  end
 
end
 
server = Server.new
 
while (input = gets)                     # Loop server while user gives an input
 
 if input =~ /start/
   server.start                          # Start the server if the user types "init"
 
 end
 
 if input =~ /shutdown/
   server.shutdown                       # Shut the server down if the user types "shutdown"
 
 break
 end
 
end

Thin provides a TCPServer Socket backend which can also be used for similar purposes. Its pretty much the same except that it uses the EventMachine library for the Network I/O.

I was recently going through a set of commonly asked interview questions and I came across a problem requiring to shuffle a deck of 52 cards in random order. Initially, I found The Knuth or The Fisher Yates shuffle the easiest algorithm to implement.

The Knuth Shuffle makes use of a certain set  of random numbers for creating randomness. Implementing it as Code, obviously required me to make use of the rand() function.

Here’s the actual description of the algorithm from The Art of Computer Programming, Volume 2: Seminumerical Algorithms, page:145. Third Edition. D.E. Knuth

Let X1, X2, …, Xt be a set of t numbers to be shuffed.

P1. [Initialize.] Set j ← t.
P2. [Generate U.] Generate a random number U, uniformly distributed between zero and one.
P3. [Exchange.] Set k ← [jU] + 1. (Now k is a random integer, between 1 and j. Exchange Xk and Xj.
P4. [Decrease j.] Decrease j by 1. If j > 1, return to step P2.

I used my favourite language Ruby to write the code and came up with this :

array = (1..52).to_a
 
lenth = array.length
 
index = (lenth-1)
 
while(index >= 0) do
 
  random_number = rand(index+1)
 
  array[random_number], array[index] = array[index], array[random_number]
 
  index = index - 1
 
end
 
puts array

One of the problem I found was the use of the rand() function.
The use of a randomize function in real life situation is not ideal, say, in a game of Poker(online). One can easily sync the time of our clock to that of the server, If the randomize function is seeded with the number of milliseconds from the system clock as was in the case of the ASF Software’s Poker product.

A Modulus operator is used for restricting the numbers in a particular range. Like in the GNU C Library’s (GlibC) strfry() which can be used for randomizing strings. 

From Wikipedia :

Doing a Fisher-Yates shuffle involves picking uniformly distributed random integers from various ranges. Most random number generators, however—whether true or pseudorandom—will only directly provide numbers in some fixed range, such as, say, from 0 to 232−1. A simple and commonly used way to force such numbers into a desired smaller range is to apply the modulo operator; that is, to divide them by the size of the range and take the remainder. However, the need, in a Fisher-Yates shuffle, to generate random numbers in every range from 0–1 to 0–N pretty much guarantees that some of these ranges will not evenly divide the natural range of the random number generator. Thus, the remainders will not always be evenly distributed and, worse yet, the bias will be systematically in favor of small remainders.

Googling around turned out that sorting it by using UUID’s as a source of random numbers was more easier to implement.
Ruby offers a library for generating UUID’s which uses /dev/urandom on *nix types systems to generate random numbers.
A GUID can be created by these two lines.

require 'guid' 
 
g2 = Guid.new  #a unique GUID every time

It’s typically not faster, as sorting would be O(n log n) compared to the O(n) (linear time) for the Knuth Shuffle.

Wolfram MathWorld has a few mathematical shuffling algorithms and randomization techniques for further mathematical reference.