Encapsulating Information and Behavior without State

Ruby
1

This should prove an interesting topic. I am currently debating two
potential means of implementing the same thing. What I have are sets
of methods and data that I need to encapsulate in one fashion or
another --lets call those the “character” of a thing. But there is no
state involved. Now, if there were state involved, the obvious answer
is to create a class encapsulating the character --one class for each
type of character. But since there is not state, to implement those as
a class means Singleton Classes. And I know there is a general meme
out there that says singleton classes are not good.

Let’s use this silliness as an example:

class Character
include Singleton
def type
self.class::TYPE
end
end

class DuckCharacter < Character
TYPE = :bird
def quack
puts “quack quack”
end
end

That’s one approach. (Note, I could use a function module, but
module’s singleton levels don’t inherit, among other things, so I
think that option is too limited.)

The other approach is to create a DSL to instantiate the character as
object, eg.

thing :duck, :type => :bird

behavior :duck, :quack do |duck|
puts “quack quack”
end

where #thing would do something like:

def thing(name, attribs={})
things[name] = Character.new(name, attribs)
end

and #behavior would add a Proc to the Character instance.

The upside here, of course, is the upside of DSLs. It’s concise and to
the point and reads well. On the downside it won’t document well under
RDoc, and I don’t get as much in the way of utilizing inheritance.

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?

Thanks.

2

Reading on the subject with regards to Java, I think what I am
considering, rather then a singleton class, is a static class. But
what does a “static class” really look like in Ruby?

3

On Thu, Dec 17, 2009 at 5:15 PM, Intransition [email protected]
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.

You should look at modeling the system in a purely functional manner,
but it
is hard
to see what you are attempting to do.

4

On Thursday 17 December 2009 09:55:03 pm Intransition wrote:

Reading on the subject with regards to Java, I think what I am
considering, rather then a singleton class, is a static class. But
what does a “static class” really look like in Ruby?

Like a singleton, or like a module with a bunch of “class methods”.

5

On Dec 17, 11:30 pm, Richard C. [email protected] wrote:

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.

6

On Fri, Dec 18, 2009 at 4:12 PM, Intransition [email protected]
wrote:

etc…
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.

7

On 18.12.2009 17:12, Intransition wrote:

If there is unique information captured in objects (encapsulation) you have

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<<self
attr_accessor :power
end

 # ... methods ...

 def self.i_ve_got_the_power
   puts "#{self}'s power is #{power}"
 end

end

class Meter < UnitType
self.power = 123
# … override methods …
end

class Second < UnitType
self.power = 456
# … override methods …
end

irb(main):022:0> 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

8

On Sat, Dec 19, 2009 at 8:58 AM, Robert K.
[email protected]wrote:

What’s wrong with doing

class UnitType

class<<self

[…]

class Second < UnitType

This is the “Ruby-like” way to do it in my mind: using the singleton
class
and inheritance. I have never found a valid reason to use singleton.rb
and
don’t really understand why it even exists. Ruby has first-class
singletons.

9

On Dec 19, 10:58 am, Robert K. [email protected] wrote:

   puts "#{self}'s power is #{power}"
 # ... override methods ...

end

irb(main):022:0> 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

Nothing. Indeed I think that is the way to do it (if the static-class
approach is taken). singleton.rb is again proven rather toothless.

thanks.