Design Patterns in Ruby by Russ Olsen | Jason Meridth’s Blog

After nudging by Joe Ocampo and Scott Bellware, I finally sat down at finished “Design Patterns in Ruby” by Russ Olsen.
The format of most of the chapters made the book an interesting read:
1. A introduction to why you might need the pattern
2. A static language developer’s approach with the Ruby language
3. A seasoned Ruby developer’s approach to the design pattern
4. Using and Abusing
5. in the wild
6. Wrapping up
Some of the items that I learned [LosTechies is not a cult contrary to some of the examples you read below; some of the examples below are using LosTechies nomenclature but closely resemble what the author had in the book]
If any of the stuff below intrigues you: GO BUY THE BOOK. You won’t regret it. Even if you are trying to understand patterns in another language. Russ Olsen does an excellent job explaining the INTENT of the patterns.
When teaching the reader about “Truth, Lies, and nil”, the author even pokes fun at himself:

'russ' == 'smart'    # sadly, false

In Ruby, zero, being neither false nor nil, evaluates to true in Boolean expression.

if 0 puts('Zero is true!')end

will print out: Zero is true!

Points for matrix reference in array examples

x = []y = Array.newa = ['neo', 'trinity', 'tank']

The flow of the language when creating regular expressions:

/old/ =~ 'this old house'     # 5 - the index of 'old'/Russ|Russell/ =~ 'Fred'      # nil - Fred is not Russ nor Russell/.*/ =~ 'any old string'      # 0 - the RE will match anything

Any author that uses DC comic character to explain arbitrary numbers of arguments, is a winner in my mind:

def describe_hero(name, *super_powers> puts("Name: #{name}") for power in super_powers     puts("Super power: #{power}") endenddescribe_hero("Batman")describe_hero("Flash", "speed")describe_hero("Superman", "can fly", "x-ray vision", "invulnerable")   # w00t!

He mentions duck typing and the fact that “Unit Tests Are Not Optional” is a section heading when teaching the Template Method Pattern.


# using the do/end notationhello = lambda do puts('Hello') puts('I am a follower of Pablo')end#you may use curly braces instead of do/endhello = lambda { puts('Hello, I am a follower of Pablo')}#the preferred way to use curly braceshello = lambda {puts('Hello, I am a follower of Pablo')}

using proc-based formatters to create a ruby-based strategy pattern

class Report attr_reader :title, :text attr_accessor :formatter def initialize(&formatter)   @title = 'Monthly Report'   @text = ['Things are going', 'really, really well.' ]   @formatter = formatter end def output_report self ) endendHTML_FORMATTER = lambda do |context|...code to output HTMLreport = &HTML_FORMATTERreport.output_report

You could create any type of formatter you want in a proc instead creating new classes.

Modules exist that encapsulate things that some of us static developers might already be used to:

require 'observer'class Employeeinclude Observableattr_reader :name, :addressattr_reader :salarydef initialize( name, title, salary) @name = name @title = title @salary = salaryenddef salary=(new_salary) @salary = new_salary changed notify_observers(self)endend

Internal Iterators versus External Iterators: (had never heard it put this way)
External iterator – client drives the iteration…you won’t call next until you are good and ready for the next element
Internal iterator – the aggregate relentlessly pushes the code block to accept item after item.

The Command pattern translates very smoothly into code blocks. Here is a PabloForPresidentButton class reworked to use code blocks:

class PabloForPresidentButtonattr_accessor :commanddef initialize(&block) @command = blockend## Lots of button drawing and management# code omitted ...#def on_button_push if @commandendendnew_button = do## Make a developer stop looking so nerdy# by placing one over his pocket protector#end

The author does not diminish the needs for classes. For straightforward actions, use a Proc object. For complex object or objects that will carry around a lot of state, create a command class.

Instead of adhering to some interface and trying to create your adapter, why not just extend the original class.

# load original classrequire 'lostechies_text_object'# now add some methods to original classclass LosTechiesTextObjectdef sponsor return friend_of_pabloenddef blogger return follower_of_pabloendend

Before any of you Open-Closed people attack, please re-read the definition of OCP – Open for extension, closed for modification. Doesn’t this adhere to that? 🙂

There are three tyes of Proxies: The Protection Proxy, Remote Proxy, Virtual Proxy
These are mentioned in the Gang of Four book. He introduces a Ruby-esqe way to approach proxies: the method_missing Method

class AccountProxydef initialize(real_account) @subject = real_accountenddef method_missing(name, *args) puts("Delegating #{name} message to subject.") @subject.send(name, *args)endendap = )ap.deposit(25)ap.withdraw(50)puts("account balance is now: #{ap.balance}")

Will output:
delegating deposit method to subject.
delegating withdraw method to subject.
delegating balance method to subject.
account balance is now: 75


module Decorator1def do_something(common_item_to_decorate) #codeendendmodule Decorator2def do_something(common_item_to_decorate) #codeendendd ='howdy')

The author admits the career of the singleton has been checkered, but still shows that you can use it in the Ruby world. An example he gives us to allow testing of singleton implementation code is to put the implementation code in a base class and have the child be the singleton:

require 'singleton'class SimpleLogger#  All of the logging functionality in this class...#  Test this codeendclass SingletonLogger < SimpleLogger

I never had it straight, exactly, what the difference between these patterns were (yes, besides name). I never bothered to look. According to the author, Factory returns back a single object while Abstract Factory is “an object dedicated to creating a compatible set of objects”. According to GoF book (which I have open in front of me), Abstract Factory “provides an interface for creating families of related or dependent objects without specifying their concreate classes”. Which one do you think would have turned the light bulb off in your head? 🙂
The other item was using “Convention Over Configuration” to generate abstract factories:

class IOFactorydef initialize(format) @reader_class = self.class.const_get("#{format}Reader") @writer_class = self.class.const_get("#{format}Writer")enddef new_reader @reader_class.newenddef new_writer @writer_class.newendendhtml_factory ='HTML')html_reader = html_factory.new_readerpdf_factory ='PDF')pdf_writer = pdf_factory.new_writer

Notice the correct classes (reader/writer) are generated dynamically with the help of the const_get Ruby method.

Magic methods: “very easy to implement using the method_missing technique…you simply catch all unexpected method calls with method_missing and parse the method name to see if it matches the pattern of your magic method name”.

#example method passed into computer builder classbuilder.add_dvd_and_harddisk#orbuilder.add_turbo_and_dvd_dvd_and_harddiskdef method_missing(name, *args)words = name.to_s.split("_")return super(name, *args) unless words.shift == 'add'words.each do |word| #next is same as continue in for loop in C# next if word == 'and' #each of the following method calls are a part of the builder class add_cd if word == 'cd' add_dvd if word == 'dvd' add_hard_disk(100000) if word == 'harddisk' turbo if word == 'turbo'endend

Last 3 Chapters are the meat of the book:
INTERPRETER PATTERN (place where Bellware told me to start)
Those stay obscure so you can go read it. I think the book is worth a visit on Safari books if you have an account or worth the purchase for the bathroom reading.
I enjoyed it. Thanks Scott and Joe

Leave a Reply

Your email address will not be published. Required fields are marked *