CSC/ECE 517 Fall 2009/wiki2 13 ncs

Introduction

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

• can dynamic typed languages realize the design patterns more effectively than statically typed languages

• Are there instances where a design pattern should be used in a dynamic language than a static language

Design Patterns in JAVA vs Ruby

Singleton Pattern

Singleton pattern is used when we wish to restict the instantiation of the class to a single pattern.

The implementation of the pattern involves

• making the constructor private
• declare a instance variable
• implement a getInstance method and make the it thread safe.

Singleton Class example in JAVA

 public class SingletonExample {
    // declare instance variable
    private static SingletonExample singletonExample;
    // Make the constructor is private
    private SingletonExample () {
    }
    // make this thread safe use synchronize
    synchronize public static SingletonExample getSingletonObject() {
      if (singletonExample == null) {
         singletonExample = new SingletonExample ();
      }
      return singletonExample ;
    }
 }

In JAVA we would need to take the above steps for every class that we want to make singleton.

In ruby we can do what we did in JAVA above or simply use the singleton module that automatically gets us the functionality listed above.

Singleton example in Ruby using the singleton module.

 require singleton
 Class SingletonExample
   include singleton
 end

Ruby provides a more concise way of implementing the singleton pattern and prevents us from havin to repeat ourselves for each class that we wish to make singleton. We can simply include the singleton module. In JAVA we will have to repeat the code from the JAVA example for each class we wish to make singleton.

Factory Pattern

Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

 interface IObjectFactory {
    IGear createObject();
 }
 class ConcreteObjectFactory implements IObjectFactory{
 IObject createObject() {
    if ( some condition )
       return new XObject();
    else
       return new YObject();
 }
 class ObjectUser {
    public void doSomething(IObjectFactory factory ) {
       IObject my_Object = factory.createObject();
    }
 }

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

 class ObjectFactory
   def new() 
     if ( ... some condition )
        return XObject.new()
     else
        return YObject().new()
   end
 end

Our client class now becomes:

 class ObjectUser 
   def doSomething(factory )
     ...
     my_object = factory.new()
     ...
   end
 end

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

Iterators

Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

• An iterator declared and initialized to point to the collection

• Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby

 a = [ 10, 20, 30, 40 ]
 a.each { |element| print "The element is #{element}\n" }

 Thread.list.each { |t| print "Thread: #{t}\n" }

 ObjectSpace.each_object { |o| print "Object: #{o}\n" }

 open("data.txt").each_line { |line| print "The line is #{line}\n" }

Conclusion

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.