From: Richard Conroy <richard.conroy@...>
Date: 2009-12-19T01:31:45+09:00
Subject: Re: Encapsulating Information and Behavior without State

--0015175dd9c6b1a326047b03343d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Dec 18, 2009 at 4:12 PM, Intransition <transfire@gmail.com> wrote:

>
>
>
> Maybe it will help if I explain how I got to this question. I started
> with a set of classes that all had one attribute, using a base class:
>
>  class UnitType
>    attr :power
>    # ... methods ...
>  end
>
> I had:
>
>  class Meter < UnitType
>    # ... override methods ...
>  end
>
>  class Second < UnitType
>    # ... override methods ...
>  end
>
>  etc...
>
> So each one was instantiated to track the power of a given unit. But
> then I realized that it would be better to couple the type and power
> via another class:
>
>  class Unit
>    def initialize(unit_type, power)
>       @unit_type = unit_type
>       @power      = power
>    end
>  end
>
> And remove the power attribute from the UnitType class. Thus I was
> left with a bunch of classes that had no state.
>
>
>
>
Okay, this makes a bit more sense. This kind of unit
representation/conversion is a common idiom in DSL
tutorials. It is quite common to patch in unit specific methods into Fixnum
to represent these. Have a google
for it.

The last code example seems pretty sound in any case if you intend to make
unit_type specific classes,
though I can see now why you are leaning towards a singleton approach.

-- 
http://richardconroy.blogspot.com

--0015175dd9c6b1a326047b03343d--