From: Robert Klemme Date: 2009-12-20T00:58:13+09:00 Subject: Re: Encapsulating Information and Behavior without State On 18.12.2009 17:12, Intransition wrote: > > On Dec 17, 11:30 pm, Richard Conroy wrote: >> On Thu, Dec 17, 2009 at 5:15 PM, Intransition wrote: >>> So that's the idea. Getting back to the main question: What's the best >>> way to encapsulate information and behavior when there is no state? >> There's a bit of a contradiction here. To paraphrase what you said: >> >> What's the best >> way to encapsulate "State" and behavior when there is no state? >> >> If there is unique information captured in objects (encapsulation) you have >> state. > > Sorry, by "information" I just meant constants (static information). > >> You should look at modeling the system in a purely functional manner, but it >> is hard >> to see what you are attempting to do. > > 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. What's wrong with doing class UnitType class< Meter.i_ve_got_the_power Meter's power is 123 => nil irb(main):023:0* Second.i_ve_got_the_power Second's power is 456 => nil ? Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/