# Encapsulating Information and Behavior without State

**URL:** <https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338>\
**Category:** Ruby\
**Created:** [December 17, 2009, 6:16pm UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338 "2009-12-17T18:16:47Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 17, 2009, 6:16pm UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/1 "2009-12-17T18:16:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 18, 2009, 5:04am UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/2 "2009-12-18T05:04:05Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 18, 2009, 5:30am UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/3 "2009-12-18T05:30:25Z")

</div>

On Thu, Dec 17, 2009 at 5:15 PM, Intransition [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 18, 2009, 5:16am UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/4 "2009-12-18T05:16:22Z")

</div>

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”.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 18, 2009, 5:13pm UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/5 "2009-12-18T17:13:51Z")

</div>

On Dec 17, 11:30 pm, Richard C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 18, 2009, 5:46pm UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/6 "2009-12-18T17:46:02Z")

</div>

On Fri, Dec 18, 2009 at 4:12 PM, Intransition [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 19, 2009, 5:08pm UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/7 "2009-12-19T17:08:09Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 19, 2009, 7:29pm UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/8 "2009-12-19T19:29:13Z")

</div>

On Sat, Dec 19, 2009 at 8:58 AM, Robert K.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [December 19, 2009, 10:03pm UTC](https://www.ruby-forum.com/t/encapsulating-information-and-behavior-without-state/180338/9 "2009-12-19T22:03:11Z")

</div>

On Dec 19, 10:58 am, Robert K. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.