Ruby Patterns and Practices

Pattern Implementations

Fri, 20 Jan 2012 13:50:14 Z

Pattern Implementations in Ruby

Share your Design Pattern implementation examples in Ruby language here.

Note that there are other very good Bob Marley’s quotes sites that discuss design patterns in general, and it’s not our goal to be one of them. The goal here is to illustrate Long Term Travel various ways of effectively applying common design patterns in the Ruby language.

A Word of Warning

Design patterns are – well – “patterns”, not concrete recipes. One pattern Virginia reckless driving can be interpreted and implemented in different contexts, scales, scopes, etc. A specific pattern implementation can help illustrate a pattern, and it can be restaurant supply a fine and useful recipe – just try not to confuse any particular implementation strategy with the danube river cruises pattern itself.

Specific Pattern Implementations

Home Page

Tue, 17 Jan 2012 16:15:53 Z

http://www.genericdrugonline.com/?s=detrol – Detrol generic – Breminal, Detrusitol, Detrusitol, Detrusitol Neo, Detrusitol retard, Dezrolala.

Use Mixins To Separate Concerns

Sun, 02 Oct 2011 18:15:32 Z

In Ruby, we tend to have more methods and fewer classes than in other OO languages. This is, IMHO, a good thing because, although “lots of small classes” is a good way to get separation of concerns, it’s very hard to do that without exposing lots of implementation concerns to the code that’s trying to make use of the behavior. We then have to create Facades and such to put all the worms back in the can, and that’s another class or 3 we have to deal with.

With mixins, we can implementation a behavior in one module that gets mixed into one or more other classes that should have that behavior, and that’s a good thing to do whenever possible.

Note that it is possible to use mixins to group related methods, yet still not successfully separate concerns. If the code in the mixin only works in tandem with a large body of functionality defined in the base class or in other mixins, the concerns have not really been separated.

A good way to ensure that the concerns are, in fact, separated is to develop mixins in a Behavior Driven (AKA Test Driven fashion). If your mixin or your spec needs to do more than limited, surgical requiring of other files, then the concerns are not well separated. You can and frequently should use mock objects to simulate a small number of external things that the mixin must interact with, but if the mocks need to be particularly complex, this again probably indicates too high a degree of coupling.

Note that since, in Ruby, a module or a class is itself a plain ol’ object, you can easily mock a class or module that will include your mixin (e.g. to mock a class method that any including class is expected to supply).


 require 'test/unit'
 require 'rubygems'
 require 'mocha'

 class ListCreatorTest < Test::Unit::TestCase

   def setup
     @mock_class = Class.new
     @mock_class.class_eval( <<-EVAL, __FILE__, __LINE__ )
       include ListCreator
       def self.inspect; '@mock_class'; end
       def self.create( attributes ); end
     EVAL
   end

   # Should really have 0-item and 1-item specs(tests) here...

   def test_creates_list_of_2
     @mock_class.expects(:create).with(1,2,3).returns('one')
     @mock_class.expects(:create).with(4,5,6).returns('two')

     result_list = @mock_class.list_create( [1,2,3], [4,5,6] )

     assert_equal ['one', 'two'], result_list

   end

 end

 module ListCreator

   def self.included( klass ); klass.extend ClassMethods; end

   module ClassMethods
     def list_create( *specs )
       specs.map{|s| create(*s) }
     end
   end

 end

Thanks to whoever improved the class_eval( <<-EVAL ... code above.

One good example of a bad example (uses modules, but still tightly coupled) unfortunately, is ActiveRecord. I was hoping to follow the principle described above in specifying and building an ActiveRecord model for a Rails application. I should, for instance, define all my validations in a single mixin and have a single spec for that. To do that, though, I would only want my test to be coupled to ActiveRecord::Validations and not to ActiveRecord::Base, or ActiveRecord::AnyOther…

Unfortunately, when I looked at the source for ActiveRecord::Validations to see if it can be used on it’s own, it’s not immediately clear – so I looked at its test. The first thing that test does is include a whole bunch of files from test/models, each of which includes ActiveRecord::Base and uses functionality from all over the map in ActiveRecord. An error anywhere in any module of ActiveRecord can break this test case! The individual tests medical transcription continue down this ugly path by only testing validation behavior by way of instances of these sewing machine cabinets classes.

Certainly, these tests do nothing to demonstrate how to cure panic attacks or what’s the best panic attack treatment. Validations could be included and used separately. Hopefully Rails3/Merb2 will improve on this.

Dependency Injection Via Situ

Mon, 16 May 2011 13:16:50 Z

Dependency injection means we want to give a code unit its dependencies at creation time rather than have them hard-wired into its definition.

There are many reasons for dependency injection, but often all we want is to test a class using mocks of its dependencies. When that’s all we need, we can arrange for a class to access its dependencies indirectly, via a “situ” method call that we can override by subclassing. I have chosen the “situ” name (from “in situ” – in its place) since it is short, reasonably clear, and not likely to clash with terms like “context” and “environment” that commonly have other somewhat different meanings in code.

Since we want situ to be accessible in the same way from the class context as from the instance context (like a Ruby constant), we define situ for the class, then define situ for the instance as an indirect call to the class-level situ method.

Class definition with overridable “situ” :


 module Questioner
   class Base

     def self.situ ; Questioner ; end
     def situ ; self.class.situ ; end

     def take_exam( q_and_a )
       ifc = situ::Interface.new
       score = q_and_a.inject(0) do |accum,qa| 
         response = ifc.ask(qa[0])
         qa[1] == response ? accum + 1 : accum
       end
       return score
     end

   end
 end

Unit test that injects a mock “situ” :


 require 'rubygems'
 require 'test/unit'
 require 'mocha'

 test_root = File.dirname(__FILE__) + '/../..'
 lib_dir = test_root + '/../lib'
 require File.expand_path( lib_dir + '/questioner/base.rb' )

 module QuestionerSuite
   class BaseTest < Test::Unit::TestCase

     def setup
       # Create dynamic situ with a mock Interface class.
       @situ = Module.new
       @situ.instance_eval( <<-HERE, __FILE__, __LINE__ )
         class self::Interface
           def ask( question ) ; end
         end
       HERE

       # Dynamically subclass Questioner::Base with injectable situ.
       @q_base_class = Class.new( Questioner::Base )
       @q_base_class.instance_eval( <<-HERE, __FILE__, __LINE__ )
         class << self ; attr_accessor :situ ; end
       HERE

       # Inject the situ into the Questioner::Base subclass
       @q_base_class.situ = @situ

       # Override inspect methods for friendly error/failure output.
       @q_base_class.instance_eval( <<-HERE, __FILE__, __LINE__ )
         def self.inspect ; '@q_base_class' ; end
         def inspect ; '@q_base_class-instance' ; end
         class situ::Interface
           def self.inspect ; '@situ::Interface' ; end
           def inspect ; '@situ::Interface-instance' ; end
         end
       HERE
     end

     def test_score_responses
       q_and_a = [
         ['question 1', 'a1'], ['question 2', 'a2'], ['question 3', 'a3']
       ]
       @mock_ifc = @situ::Interface.new

       @situ::Interface.expects( :new ).returns( @mock_ifc )
       @mock_ifc.expects( :ask ).with( 'question 1' ).returns( 'a1' )
       @mock_ifc.expects( :ask ).with( 'question 2' ).returns( 'wrong' )
       @mock_ifc.expects( :ask ).with( 'question 3' ).returns( 'a3' )

       questioner = @q_base_class.new

       score = questioner.take_exam( q_and_a )

       assert_equal 2, score
     end

   end
 end

When employing this technique, some outside code should be accessed only via situ and other outside code should be directly referenced. A unit should use situ to access its peers (i.e. other modules and classes nested in the same module) and other layers (i.e. a controller referencing a model), but should directly reference built-in classes and widely used utilities – things you would not want or need your unit test to be aware about the usage of.

Now, to facilitate reusing this pattern, we can write some test helper methods for building the dynamic mock modules and classes, and defining their “inspect” methods for friendly error/failure output. For illustration purposes, the example below has the helper module defined in the same file as the test.

Note that, for some reason, the Textile processor decided to format parts of this code block, so you’ll have to fix some curly quotes and apostrophes, and put the double-underlines back around FILE and LINE to use the code.


 require 'rubygems'
 require 'test/unit'
 require 'mocha'

 test_root = File.dirname(__FILE__) + '/../..'
 lib_dir = test_root + '/../lib'
 require File.expand_path( lib_dir + '/questioner/base.rb' )

 module TestHelper

   # Dynamically creates an anonymous module or class for
   # mocking, or a suclass for dynamic modification.
   # To create a new class or module, pass Class or Module
   # as the kind.  To create a new anonymous subclass pass
   # the intended superclass as the kind.
   # Remaining parameters are symbols for the nested target
   # instance variable or constant where the newly created
   # class/module will be placed.  This sequence is also
   # used to define return values for inspect method calls,
   # so test failure/error reports are easy to interpret.
   # All items except the last in the target chain must
   # already exist before calling this method.
   #
   # Example:
   # instrument Module, :@mock_situ
   # instrument Module, :@mock_situ, :FooMod
   # instrument Class, :@mock_situ, :FooMod :BarClass
   def instrument( kind, *target_chain )
     if kind  Class || kind  Module
       new_mod = kind.new
     elsif Class === kind
       new_mod = Class.new( kind )
     else
       raise ArgumentError, 
             “kind must be Module, Class, or a suclass of Class.” 
     end

     insp_val = target_chain.join(’::’)
     new_mod.module_eval “def self.inspect ; ’#{insp_val}’ ; end” 
     if Class === kind
       new_mod.module_eval(
         “def inspect ; ’#{insp_val}-instance’ ; end”, FILE, LINE )
     end

     # Drill down through the target’s ancestors
     target_in = target_chain[0…-1].inject(self) do |t_in,t|
       Module === t_in ? 
         t_in.module_eval( ”#{t}” ) :
         t_in.instance_eval( ”#{t}” )
     end
     target = target_chain.last

     if target.to_s[0..0] == ’@’
       target_in.instance_variable_set target, new_mod
     else
       target_in.const_set target, new_mod
     end
   end

   # Create a new class attribute accessor, and optionally
   # assign an initial value to the attribute.
   def put_class_attr( claz, attr_name, attr_val=nil )
     claz.class_eval “class << self ; attr_accessor :#{attr_name} ; end” 
     claz.send ”#{attr_name}=”, attr_val
   end

 end

 module QuestionerSuite
   class BaseTest < Test::Unit::TestCase
     include TestHelper

     def setup
       instrument Module, :@mock_situ
       instrument Class, :@mock_situ, :Interface
       instrument Questioner::Base, :@q_base_class 
       put_class_attr @q_base_class, :situ, @mock_situ
     end

     def test_score_responses
       q_and_a = [
 [‘question 2’, ‘a2’], [‘question 3’, ‘a3’]
       ]
       @mock_ifc = @mock_situ::Interface.new

       @mock_situ::Interface.expects( :new ).returns( @mock_ifc )
       @mock_ifc.expects( :ask ).with( ‘question 1’ ).returns( ‘a1’ )
       @mock_ifc.expects( :ask ).with( ‘question 2’ ).returns( ‘wrong’ )
       @mock_ifc.expects( :ask ).with( ‘question 3’ ).returns( ‘a3’ )

       questioner = @q_base_class.new

       score = questioner.take_exam( q_and_a )

       assert_equal 2, score
     end

   end
 end

keen
Kerala India
pos software

car-shipping

Wed, 10 Nov 2010 21:35:27 Z

Car shipping is the auto transport of a vehicle from a seller in one place to a buyer in another place. This includes country to country shipping as well as state to state shipping. Auto transport and shipping was largely a commercial activity conducted by dealers, manufacturers and brokers until the last ten to fifteen years. The explosion of Internet use has allowed this niche service to grow and reach the general consumer marketplace.

Before the Internet ###
Prior to the Internet, people had to purchase cars from local dealers due to the difficulty in transporting a vehicle from its point of origin to the purchaser’s place of residence. While freight businesses did exist, this method of transporting a vehicle was generally expensive and not cost efficient. Freight shipping is still based on increments of weight, and can cost you quite a bit more than a specialized car transport company that charges based on distance or other basis. Due to this cost, the shipment of automobiles was restricted to those who had the money to purchase both the car and the transport.

Advances from the Internet ###
This car shipping industry has grown explosively since the advent of the Internet. People are now able to purchase cars from anywhere in the world and have them shipped to their doorstep. In fact, more and more dealerships are marketing online towards people from all over the world. Even the small used car dealers are selling cars online. These businesses are finding that these online sales are accounting for more and more of their profits. Ebay and other online market places have provided customers with an endless supply of choices. People can now search online to find the perfect car, both new and used. Collectible cars make up a large portion of the cars that are purchased via the Internet. Because rare and collectible cars are limited, people have turned to the Internet to find the car of their dreams. In most cases, the car that they want is not local, and the person must find a way to transport the vehicle. Because of this need, car transport companies have come into the picture.

Car transportation ###
There are basic steps that each consumer must take when moving a car. When a car is shipped, it is loaded onto a carrier. This carrier is what transports a vehicle to a new place. Before shipping, each car must be subjected to records and search engine marketing inspections. Records of damage and other markings of a vehicle are kept so that a company is not liable for damage that did not occur during transport.

Tight Coupling In Active Record Rant

Fri, 20 Feb 2009 09:14:55 Z

Ruby mixins are a great way for us to have our cake and eat it too. We can have classes that are rich in functionality across many areas of concern that are often convenient to lump together, yet still be able to mix in just the bits we need in other cases.

ActiveRecord ought to be a case in point. It has functionality to…

Load and save records
Validate data
Provide entity-identification for use in URLs
Massively assign attributes from a hash (including field parts for dates, etc.)
...

All of these capabilities ought to be independently mixable rather having to get them all by inheriting from ActiveRecord::Base.

Frequently, we’d like to do something like post form data to a non-persistent model object with validation. This turns out to be surprisingly difficult to do, and much bad Rails code is written as a result (business logic scattered about in the controllers, etc.) Since some of this stuff ought to have no necessary connection to storage, it should ideally not even be defined directly in ActiveRecord, but should be mixed in from modules with other names.

Note that I’m not recommending any kind of DAO architecture rather than using the ActiveRecord pattern. Using Ruby mixins, we’re not supposed to always add more layers to adequately separate our concerns.

Ideally, we should be able to say something like…


 class CustomerReport
   include ActiveSupport::Validation
   include ActiveSupport::MassAssignment

   # One or 2 lines to tell mixins what methods to intercept

 end

The best work-around I’ve found is http://agilewebdevelopment.com/plugins/activerecord_base_without_table. It’s kludgey, and to use it with Rails 2.x, you’ll have to manually edit the file and change readmethods to generated_methods, but it’s infinitely better than nothing. I highly recommend using this plugin.

category: Rant

Rants

Fri, 20 Feb 2009 09:12:51 Z

When you just need to vent…

Tight Coupling in ActiveRecord

category: Rant

Best Practices

Wed, 18 Feb 2009 07:59:30 Z

Practices

External Links

21 Ruby Tricks…

category: Starting Points, Best Practices

Use Mixins to Separate Concerns|

Wed, 18 Feb 2009 07:59:00 Z

(Delete me)
This content has been moved to Use Mixins To Separate Concerns

Write Automated Specifications (AKA Tests)

Wed, 18 Feb 2009 07:56:23 Z

(Delete me)
This content has been moved to WriteAutomatedSpecs

Write Automated Specs

Wed, 18 Feb 2009 07:54:28 Z

Yes, we’re talking about writing “Tests”, but also following the new trend to refer primarily to “Specifications” instead, since that’s really what we are trying to create. We’re writing code that acts as a specification for how we’ll want to invoke some program functionality and how it is expected to behave under various conditions.

There are still good reasons to use tools such as Ruby’s built-in Test::Unit in some cases rather than tools using the Specification/Behavior language of BehaviorDrivenDevelopment?, but regardless of the tool being used, think in terms of writing verifiable specifications.

More to come…

category: Best Practices

Abstract Factory Via Module New

Fri, 13 Feb 2009 21:55:13 Z

Just as in the Abstract Factory: alias <class>.new implementation, using this abstract factory implementation or refactoring to it should have no impact on the code that uses it. Basically, instead of using the default new method behavior of a named class to build instances of that class, we use the new method of a named module to build arbitrary class instances for us.

Since, unlike in the Abstract Factory: alias <class>.new, we’re defining new for a module instead of redefining it for a class, we don’t have to do any tricks with aliasing a class’ built-in new method.

A Trivial Example

 module Foo

   module Base

     class Abstract
       attr_reader :name
     end

     def Base.new( name )
       concrete_class = const_get( name )
       concrete_class.new
     end

     class Bar < Abstract
       def initialize; @name='--BAR--'; end
     end

     class Baz < Abstract
       def initialize; @name='--BAZ--'; end
     end

   end

 end

# Try it out...
puts Foo::Base.new('Bar').name

Output:

##BAR##

Variations:

Factory as a class rather than a module

Since the factory module is not the thing we’re making instances of, it doesn’t really matter if it’s a module or a class – so we could make it a class. That’s misleading though, since the purpose of a class is to be something to have instances of, and we would never have an instance of that class.

Useful Mixin Example With Unit Test Case

Note that you’ll need to unindent this code by one space to use it since the close of the EVAL here-document must be at the beginning of the line.


 require 'test/unit'

 class NamedClassAbstractFactoryTest  < Test::Unit::TestCase

   def setup
     @factory = Module.new do |m|
       include NamedClassAbstractFactory
       m.module_eval <<EVAL
         class Foo; end
         class Bar; end
         constructs Foo, Bar
 EVAL
     end
   end

   def test_creates_foo_by_name
     obj = @factory.new( 'Foo' )
     assert_equal @factory::Foo, obj.class
   end

   def test_rejects_creation_by_unknown_name
     assert_raise( ArgumentError ) do
       obj = @factory.new( 'Baz' )
     end
   end

 end

 module NamedClassAbstractFactory

   def self.included(m)
     m.extend ClassMethods
     m.const_set :Constructable, {}
   end

   module ClassMethods

     def constructs( *classes )
       classes.each do |klass|
         name = klass.name.split('::').last
         self.const_get(:Constructable)[name] = klass
       end
     end

     def new( name )
       klass = self.const_get(:Constructable)[name]
       unknown_class( name ) unless klass
       klass.new
     end

    private

     def unknown_class( name )
       raise ArgumentError, "I don't know how to create a #{name}." 
     end

   end

 end

category: Pattern Implementations

Abstract Factory Via Alias New

Fri, 13 Feb 2009 08:17:32 Z

The ultimate in loose coupling is when the calling code doesn’t have to know anything about the implementation. If we simply follow the convention of using the new class-method of the base class to create an instance, we completely isolate the decision of whether an abstract pattern is used from the calling code. From the caller’s perspective, just follow the usual conventions, and the right thing will happen.

The difficulty in trying to do this is that the new implementation in the base class must call new for a subclass for a new instance of that, but we’ve overridden new in the base class, so it has been overridden for the subclasses we’re trying to instantiate as well.

A nice solution to this problem is to alias (rename) the original new method before implementing our own. We can then access the functionality normally performed by new via its alias.

A Trivial Example

 module Foo

   class Base
     attr_reader :name

     class << self
       alias :construct :new

       def new( name )
         Foo.const_get(name).construct
       end

     end

   end

   class Bar < Base
     def initialize; @name='##BAR##'; end
   end

   class Baz < Base
     def initialize; @name='##BAZ##'; end
   end

 end

 #Try it out...
 puts Foo::Base.new('Bar').name

Output:

##BAR##

Variations:

Implement `inherited` to `undef` the `new` method on subclasses.

It’s a bit odd that our concrete classes now inherit the new method from the factory/base class. That shouldn’t be a big deal since the whole point is to use the base class as the factory and not refer to the subclasses directly. Still, if that seems too smelly, you can use the inherited callback to undef the new method in subclasses. By this point, though, the Abstract Factory: <module>.new implementation starts to look much simpler.

category: Pattern Implementations

Steve Jorgensen

Wed, 11 Feb 2009 10:48:10 Z

Steve Jorgensen is a software developer working in Ruby, Java, VB Classic, and VBA.

Design Pattern References

Wed, 11 Feb 2009 10:09:06 Z

Design Pattern References

Here are some external references to sites discussing design patterns in general (not Ruby-specific).

Ruby Patterns and Practices

Pattern Implementations

Pattern Implementations in Ruby

A Word of Warning

Specific Pattern Implementations

See Also

Home Page

Use Mixins To Separate Concerns

Dependency Injection Via Situ

car-shipping

Tight Coupling In Active Record Rant

Rants

Best Practices

Practices

External Links

Use Mixins to Separate Concerns|

Write Automated Specifications (AKA Tests)

Write Automated Specs

Abstract Factory Via Module New

A Trivial Example

Variations:

Factory as a class rather than a module

Useful Mixin Example With Unit Test Case

Abstract Factory Via Alias New

A Trivial Example

Variations:

Implement inherited to undef the new method on subclasses.

Steve Jorgensen

Design Pattern References

Design Pattern References

Implement `inherited` to `undef` the `new` method on subclasses.