Solving Design Anti-Patterns in Ruby: Fix the Factory

In the previous article, we examined some common coding anti-patterns used by programmers new to Ruby. This article will explore some of the design anti-patterns Ruby Rookies often apply to their solutions, offering some alternatives using of one Ruby’s most used constructs: the Module.

The Factory Fallacy

Developers who come to Ruby from Java tend to have a particular fondness for factory classes and methods. Many new Ruby-ists will write their factories like this:

class Shape
  def initialize(*args)
    # code for dynamically creating attributes from args list
  end
  def draw
    raise "not allowed here"
  end
end

class Triangle < Shape
  def draw
    "drawing triangle"
  end
end

class Square < Shape
  def draw
    "drawing square"
 end
end

# ...more shapes here

class ShapeFactory
  def self.build(shape, *args)
    case shape
    when :triangle
     Triangle.new(*args)
    when :square
     Square.new(*args)
    when :circle
      Circle.new(*args)
    end
  end
end

They can now decide on the fly what kind of shape they want to create, using a common constructor method.

puts ShapeFactory.build(:triangle, 3, 2, 45)
puts ShapeFactory.build(:square, 5)

There’s nothing seriously wrong with this approach, apart, of course, from the fact that it’s totally unnecessary. The clues are there: we have this Shape base class that doesn’t really add any value to our code other than to serve the class hierarchy. Also, the fact that we have a separate class (ShapeFactory) for something that any Ruby class can easily do by itself (i.e. dynamically create instances of itself) leaves a bad taste in the experienced Ruby-ist’s mouth. This design style is often followed by proponents of class-oriented languages like C# or Java, where everything has to fit in a class hierarchy. Ruby, on the other hand, is object-oriented, so everything —even classes— are objects and class hierarchies are not always necessary. With that in mind, we can think about the factory pattern like this:

We want to create objects of a generic ‘type’, but have object-specific behaviour.

Or, even:

We want to create specialized objects in a abstracted manner.

Modules as Object Decorators

A Ruby Module sits somewhere between Java’s Interface and C#’s Abstract Class, but is more flexible than either of them. Let’s re-design our Shapes solution using modules:

class Shape
  def initialize(*args)
  end
end

module Triangle
  def draw
    "drawing triangle"
  end
end

module Square
  def draw
    "drawing square"
  end
end

We can extend a Shape object with some specialized behavior:

triangle = Shape.new( 3, 2, 45).extend(Triangle)
square = Shape.new(5).extend(Square)

We’re now dynamically decorating our shapes with the behavior we need, so our triangle is a Shape the behaves like a Triangle

puts triangle.draw
=> drawing triangle

In the process, we’ve done away with the class hierarchy, the Factory class, and produced cleaner and leaner code. Sweet.

‘Type’ Withdrawal Symptoms

Some people may feel uneasy with the fact that a triangle is a Shape that behaves like a Triangle, not a ‘real’ Triangle:

p triangle
=> #<Shape:0x00000000956d98>

If you’re one of these people, rest assured: Ruby is flexible enough to accommodate anyone’s needs. We can easily track ‘type’ using Module’s hook methods:

class Shape
  attr_accessor :type

  def initialize(*args)
    @type = []
  end
end

module Triangle
  def draw
    "drawing triangle"
  end

  def self.extended(mod)
    mod.type << :Triangle
  end
end

Now we can tell exactly what ‘type’ we’re dealing with:

triangle = Shape.new( 3, 2, 45).extend(Triangle)
puts triangle.type
=> Triangle

You may have noticed that the type attribute is an Array. This is because we can potentially extend a Shape with more than one Module. The following is semantically correct although conceptually nonsensical:

my_shape = Shape.new( 3, 2, 45).extend(Triangle).extend(Square)
puts my_shape.type
=> Triangle Square

The catch here is that the newest module extension will override any existing methods with the same name. So calling the draw method on our shape will now draw a Square. Ruby gives us great power, but it’s up to us to use it sensibly.

I^3^ (Inheritance Inhibits Implementation)

Let’s re-visit our rookie Shape design. This time, we need to be able to create 3-dimensional shapes, as well as 2D ones. The most basic approach would be this:

Although this design works, it presents us with a maintenance problem. Namely, it effectively doubles our code-base. Not only do we have twice the number of shapes to maintain, but our Factory also doubles in size. More observant Rookies will try to mitigate this problem by noticing that many 3D shapes are just 2D shapes extended along the Z-axis. A Cube is just a 3D Square, a Cylinder is but a 3D Circle, and so on. So they may add an extra method into the 2D shapes that transforms them into 3D.

This approach will certainly trim down the class hierarchy and save some coding, but it presents a new set of problems:

1. If we have the #transform method in our base class, then every derived class will carry this method even if it can’t use it (i.e.Pyramid) so we get redundancy in our design.
2. We can eliminate redundancy by adding the #transform method only to the classes that need it, but then we end up with a lot of duplication.
3. We are likely to break the Liskov Substitution principle (that’s the L in SOLID Design Principles)). By transforming a 2D Shape into a 3D one we invalidate its draw method, which means that we can’t substitute a 2D with a 3D object unless we override #draw first.

These problems are caused by the core issue that, although the draw behavior applies to all types of shapes, its implementation is fundamentally dependent on the shapes’ dimensions. There seems to be no way to overcome these without returning to our previous multi-branch class design. It appears we can’t have lean, flexible code while correctly modeling our problem domain. Or can we? Once again, Modules come to the rescue.

Method Injection

We will use the ThreeD module to ensure our Shapes have the correct behavior. When we extend a shape object with it, the ThreeD module will inject the correct implementation of the #draw method into the object, overriding the existing implementation. We’re turning a previous weakness to our advantage:

class Shape
  attr_accessor :type
  def initialize(*args)
    @type = []
  end
end

module Triangle
  def draw
    "drawing triangle"
  end
  def self.extended(mod)
    mod.type << :Triangle
  end
end

module Square
  def draw
   "drawing square"
  end
  def self.extended(mod)
    mod.type << :Square
  end
end

module ThreeD
  def self.extended(mod)
    mod.type << :ThreeD
    case mod.type.first
    when :Triangle
      mod.instance_eval do
        def draw(depth)
          puts "drawing a Wedge"
        end
      end
    when :Square
      mod.instance_eval do
        def draw(depth)
          puts "drawing a Box"
        end
      end
    end
  end
end

The ThreeD module uses the type attribute to determine what type of Shape it is extending and dynamically creates the appropriate draw method for it. Any other methods already mixed-in by previous Modules remain in place. Check it out:

sq = Shape.new.extend(Square)
puts sq.draw
=>  drawing square
sq.extend(ThreeD)
puts sq.draw(4)
=> drawing a Box
puts sq.type
=> Square ThreeD

This way, a shape has only the behavior it needs and only when it needs it. No duplication, no redundancy and a SOLID design.

Summary

Inheritance and factory-based designs are necessary (sometimes, the only) design choices in many languages. However, they’re not always the best way to model certain real life problems. Ruby is a multi-paradigm language and, as such, offers some more creative design alternatives. In this article, we used Modules and Ruby metaprogramming techniques to eliminate factories and complex or inadequate class hierarchies. I hope you enjoyed it.

Are there any anti-patterns that you find in code often? How do you mitigate these anti-patterns?