On Apr 9, 7:32 am, Shin guey Wong <sgwong... / hotmail.com> wrote:
>
> Yes, but we can achieve the same thing by inherit a class which will get
> all the methods also.I know we can mixin multiple classes but only
> inherit 1 class.
> If there is only 1 class/module, which we should use? create a module or
> class?
>

You need to approach this issue in terms of semantics rather than
behaviour. It's true that inheriting from a class and including a
module are very similar in behaviour. However, in terms of semantics
classes and modules are miles apart:
- Look at the Ruby standard library. Module names are usually
adjectives (often ending in -able) while classes are usually nouns.
The meaning is that modules are meant to be containers of
functionality which is not dependent on a specific object, but is
potentially useful for many (Comparable, for instance, is useful not
only for numbers, but also for strings, which are unrelated classes).
Classes, on the other hand, are used to instantiate items which can be
manipulated further. To give a real world-like example, classes are
blueprints from which machines can be built. Modules are more like
expansion packs, which can be plugged in existing machines to extend
their behaviour.
- Even when Modules are named with nouns, the semantics remain. For
instance, the Math module is clearly a container of functionality
(maths functions, in this case). A Math object wouldn't make much
sense (you can't manipulate maths, it's just a given set of laws you
can choose to use).
- Don't forget that inheritance also has a strong semantic meaning: it
represents strictly an "is-a" relationship between objects. Use it
only if both your classes should be instantiatable, and if the
subclass could, for all intents and purposes, replace the superclass
in every case the superclass could be used (a subclass should only
refine behaviour, and only redefine it if it doesn't jeopardise this
"is-a" relationship). Including a module, on the other hand, has a
looser semantic meaning: it represents a "has-a" relationship,
indicating that the object including the module gains the
functionality contained by the module, and that it makes sense for it
to have it.

I know it looks like a lot to consider in a 1 module/class case.
However, I'd still advise you to give it full attention and decide on
using a module or a class based on semantics rather than just
behaviour. First, you never know whether what you're doing right now
won't need to be extended later, and it will be easier if the
semantics make sense. Second, by thinking this through in a simple
case, you train yourself to think semantically in more complicated
cases, where you have more chunks of functionality to account for and
more complicated configurations to disentangle.

So stop looking just at adding methods to a class. Take a step back
and consider what those methods together *define*. Do they define
something that could be considered an object, a machine or item that
could be meaningfully manipulated? Then make it a class, and subclass
from it (if you can maintain the "is-a" relationship). If those
methods define just a chunk of functionality, rather than describe an
object, put them in a module, and include it in a class.