Simone Carletti's Blog » design patterns

Ruby Proxy Pattern and Dynamic Delegation with ActiveSupport BasicObject

Simone Carletti — Thu, 13 May 2010 07:55:30 +0000

This article targets Rails 2.3 and Rails 3. The information contained in this page might not apply to different versions.

This is article is part of my series Understanding Ruby and Rails. Please see the table of contents for the series to view the list of all posts.

If you looked into the changes in Ruby 1.9, chances are that you already noticed Object is no longer the class at the top of the object-hierarchy in Ruby.

1
2
3
4

ruby-1.8.7-p249 > String.ancestors
# => [String, Enumerable, Comparable, Object, Kernel]
ruby-1.9.1-p378 > String.ancestors
# => [String, Comparable, Object, Kernel, BasicObject]

Prior 1.9, every Ruby object is a child of Object or, from an other point of view, Object is the parent of every object including Class and Modules.

1
2
3
4
5
6
7

ruby-1.8.7-p249 > String.ancestors
# => [String, Enumerable, Comparable, Object, Kernel]
ruby-1.8.7-p249 > String.class
# => Class
ruby-1.8.7-p249 > String.class.ancestors
# => [Class, Module, Object, Kernel]
ruby-1.8.7-p249 >

In Ruby 1.9 the grandpa role is played by a new special object called BasicObject. BasicObject can be considered a minimalist Object, an object with a very few defined methods.

1 2	ruby-1.9.1-p378 > BasicObject.instance_methods => [:==, :equal?, :!, :!=, :instance_eval, :instance_exec, :__send__]

Proxy Pattern and Dynamic Delegation

For the most part of Ruby code, this change won’t mean anything special. However the BasicObject plays a fundamental role to implement the proxy pattern and dynamic delegation.

Let me show you an example. Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.

Here’s a super simple bank Account.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end

and here’s our AccountLogger class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class AccountLogger

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end

The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.

Let’s run a few operations on a new bank Account.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

account = AccountLogger.new(10)

account.operations
# => [[:initialize, [10]]]

account.balance
# => 10
account.operations
# => [[:initialize, [10]], [:balance, []]]

account.deposit(20)

account.balance
# => 30
account.operations
# => [[:initialize, [10]], [:balance, []], [:deposit, [20]], [:balance, []]]

So far, everything seems to work as expected. The AccountLogger is executing all the operations without complaining and it also logs every single operation in the internal stack.

But let’s try something different. Let’s print the human-readable representation of the Account.

1
2
3
4
5
6

account.inspect
# => Amount: 30
"#"

account.operations
[[:initialize, [10]], [:balance, []], [:deposit, [20]], [:balance, []]]

Hey, it doesn’t work! Not only it returns a messy response, it also forgot to log the call. The problem is that #inspect is actually defined in our AccountLogger.

#inspect is an instance method of the Object class and because every object inherits from Object, then our AccountLogger responds to #inspect. The method_missing is never triggered and our proxy miserably fails to work.

Here we have a serious method clashing problem. Because we can’t change our Account implementation, we need to manually remove every method in the AccountLogger class which might conflict with the Account object.

1
2
3
4
5
6
7

class AccountLogger

undef_method :inspect

# ...

end

This is an error-prone approach, usually not applicable for libraries with a complex API.

Here comes the BasicObject. BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

At this point, we can change the AccountLogger to inherit from BasicObject.

1
2
3
4
5

class AccountLogger < BasicObject

# ...

end

If you are looking for a real-world example, check out the Refactoring & Dynamic Delegator video from Railscasts.

What about BasicObject in Ruby 1.8?

There have been plenty of hacks and attempts to create a BasicObject in Ruby 1.8 with many different approaches: Sequel::BasicObject, HTTParty BasicObject and Builder::BlankState.

The latter is by far the most famous BlankObject implementation for Ruby 1.8. AFAIK it has been the real first attempt to introduce a basic object in the Ruby community and, if remember well, the Ruby 1.9 core implementation was largely inspired by the Builder library.

Recently, a proposal have been made to back-port BasicObject to Ruby 1.8.8. Here’s Matz comment:

I see very little (virtually no) chance for the idea, that even enhance the gap between 1.8 and 1.9.

BasicObject and Rails

At this point, it’s time to talk a bit about Rails. After all, this series is called understanding Ruby and Rails. As you might guess, ActiveSupport provides its own implementation of the BasicObject called ActiveSupport::BasicObject.

Actually, in Rails 2.3.5 it doesn’t create anything new. It simply returns a modified instance of BasicObject or Builder::BlankSlate depending on whether the Ruby version is 1.9 or not.

The library has been modified in Rails 3 dropping the Builder dependency. That said, in Ruby 1.8.7 you can define a BasicObject-like object in 4 lines of code:

1
2
3
4
5

As usual, if you need to inherit from a BasicObject in your Rails code, use ActiveSupport::BasicObject. In this way you don’t have to reinvent the wheel again and you can safely rely on a cross-version implementation.

Refactoring to Design Patterns (phpDay 2009)

Simone Carletti — Tue, 19 May 2009 12:15:41 +0000

The slides from my Refactoring to Design Patterns talk at phpDay 2009 are now available. The presentation is hosted on SlideShare, while the source code is available as a Git repository on GitHub. Both video and presentation are available under the Creative Common Share-Alike license.

This session can be considered a natural evolution of my previous Design Patterns in PHP talk at the PHPCon: less patterns, more details, better examples!

Source Code

If you enjoyed the presentation (or even if you didn’t), please take a minute to review the talk and leave a feedback. I’m really looking forward to reading your comments!

For those who missed the conference, my talk has been recorded and published on Vimeo. Unfortunately, the quality is poor, but it’is better than nothing.

Design Patterns in PHP (PHPCon Italia)

Simone Carletti — Mon, 23 Mar 2009 08:52:53 +0000

The slides for my talk about Design Patterns in PHP at the PHPCon Italia are now available through SlideShare.

I want to thank you everyone who came to my talk. It was really a big gratification to see such many people in the room. Unfortunately I didn’t have enough time to talk about all patterns I originally included into the presentation, however I decided to not remove them from the slides.

Before making the slides available, I took the time to improve the code examples replacing all the screenshots with syntax-highlighted text. This change made the code more readable and, off course, available for cut & paste.

Due to the high interest in Design Patterns, I’m planning to publish some more resources in the future along with examples and implementations.

I do not exclude a talk or perhaps a workshop at the upcoming phpDay 2009. I’m thinking about a Refactoring to Patterns session, with live code refactoring supported by unit tests. There is not official confirmation yet, much depends on the time I have available in the next weeks.

Stay tuned!

Design Patterns in Ruby Book Review

Simone Carletti — Tue, 03 Mar 2009 12:20:35 +0000

Design Patterns in Ruby (US | UK) is the first book entirely dedicated to the implementation of the most common Design Patterns in Ruby as defined by the Gang of Four (GoF). Design Patterns in Ruby is written by Russ Olsen, edited by Addison-Wesley and is a part of the Professional Ruby Series managed by Obie Fernandez. This series is without a doubt synonymous to quality and guarantee for those looking for a book on Ruby or Rails.

Compared to my last readings, this publication was decisively less time consuming. I finished the book in no more than a week, dedicating an hour a day in tram. On condition that you have a certain familiarity with Ruby and Object Oriented Programming, Design Patterns in Ruby is a quick and involving reading.

Structure

The book is divided in three parts.

The first part, Patterns and Ruby, is a quick introduction to the design patterns and the Ruby programming language. As I said before, you should not rely too much on the second chapter. A single section is not enough to demonstrate the power of the Ruby language.

The second part, Patterns in Ruby, is the heart of the book. Each chapter covers one of the different patterns originally discussed by the GoF, providing a brief introduction, practical examples of the Ruby implementation and a few real world examples, inspired by famous Ruby libraries such as Rails and URI. At the end of each chapter, a summarizing paragraph wraps up the most important Design Pattern elements.

The third part, Pattern for Ruby, takes into consideration three patterns not included in the original book but emerged with the introduction and the development of the Ruby language.

Design Pattern discussed

This is the list of all design patterns discussed in the book:

Template
Strategy
Observer
Composite
Iterator
Commands
Adapter
Proxy
Decorator
Singleton
Factory
Builder
Interpreter

These are the Ruby-oriented patterns covered in the third chapter:

Domain-Specific Language (DSL)
Meta-Programming
Convention Over Configuration

Requirements

As stated in the preface of the author, in order to read this book you don’t need to hold any particular competence either in Ruby or Design Pattern. Even so, you should have a certain familiarity with the dynamics of the object oriented programming. I confess to finding myself partially disagreeing. Tackling the reading in this book without a certain amount of knowledge of Ruby could prove itself as counter-productive, considering that some design patterns use characteristics like meta-programming, reflection, modules, symbols, Mixins, blocks, and procedures. While the previous can be considered common aspects in many languages, starting from symbols onwards, you find yourself entering in the Ruby world.

The second chapter of the book offers a brief introduction to Ruby, but these 30 minutes of reading are nothing compared with the experience you can learn with a day-by-day programming or a Ruby book such as the excellent Learn to Program or Programming Ruby, one of the most complete Ruby references.

You don’t need any specific Design Pattern knowledge in order to appreciate this book. I agree with the author in this case. It covers all Design Patterns from theory to the practical implementation providing you with a full overview of the subject.

In conclusion

Once more, the Addison-Wesley and the Professional Ruby Series completely met my expectations. I strongly suggest the book Design Patterns in Ruby (US | UK) to all those programmers who wish to improve their Ruby development knowledge and leverage their skills to an even more professional level. Design Patterns are an advanced and professional solution to the most common software development problems and should be part of every professional developer.

Russ Olsen had the ability to write an easily readable publication, without compromising the quality of the book. Each chapter is self-contained and they can be read in no specific order. If I must find a dislike, then I would say the price could be lower, compared to the average price of similar books. But you know, quality has its price.

Where to Find Design Patterns in Ruby

You can get a printed or Kindle copy at Amazon.com, Amazon.co.uk, or at your other favorite book seller.