From: Intransition <transfire@...>
Date: 2009-12-18T02:15:54+09:00
Subject: Encapsulating Information and Behavior without State

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.