From: Gavin Sinclair <gsinclair@...>
Date: 2003-02-12T02:34:06+09:00
Subject: Re: inheriting from base classes

On Wednesday, February 12, 2003, 4:05:43 AM, dblack wrote:

>> At the end of the day, the fewer methods per class, the better.
>> Superfluous methods cloud the intention of the class.  (String et al
>> are excluded from this rule for obvious reasons.)

> This comes back to the original question -- why?  Especially in a
> language where runtime objects may or may not correspond to the
> capabilities of their (historical) class.

The fact that Ruby allows such runtime shenanigans doesn't mean that
they are commonly used.

In most cases, for better or worse, a Ruby object will have exactly
the same methods it was born with.

Runtime tricks are more likely to be used behind the scenes, where the
author of the class knows what is going on.  Weird singleton objects
are unlikely to be foisted upon the public, because:
 - such techniques are rarely needed
 - the user can't look up the documentation for a method that isn't
   'supposed' (not a moral judgement) to exist

The point I'm trying to make is that the ultra-dynamic features of
Ruby are generally used in libraries, frameworks, etc., behind the
scenes.  When John Q Programmer sits down to nut out an application,
he is 99% likely to take a similar approach in Ruby as he would in
Java, except that he notes he is free to do many things should the
need arise.  That is: identify some classes, perhaps a hierachy,
imagine the relationships between them, and bang out some
(conservative) code.  Test and repeat until it works.

That's not to suggest that the advanced features of Ruby are a mere
curiosity.  Far from it.  But if you look at the average case, and
start this debate again, then you might agree with the following
conclusion:

  At the end of the day, the fewer methods per class, the better.
  Superfluous methods cloud the intention of the class, and make
  documentation (the other half of programming) difficult.  The lower
  quality of documentation multiplies the obfuscation of your total
  system with each class, up to and beyond the point where your
  daylight hours are plagued by endless questions from the users.

Really, all these "OO rules of thumb" have scalability in mind.  As
systems grow large, it becomes more beneficial to keep each component
small, localised, and clear.

Gavin