Include module and class inheritance? which one to choose?

What is the different between the including a module and inherit a
class?

For me, there seems to be almost the same. The only thing is module can
be think as an abstract class which is not instantiate able.

If you include a module, you get all the methods from the module. You
can override the function and call super to call the method from the
module. This look the same as the class inherit.

So, I am confusing on which one should I use? Create a module, include
it or create a class and inherit it?

Thanks.

A module is simply a place where you can store methods.

Thus, you can include a module as a mixin in a class, and it will get
all the methods.

Julian.

Learn Ruby on Rails! Check out the FREE VIDS (for a limited time)
VIDEO #3 out NOW!
http://sensei.zenunit.com/

Julian L. wrote:

A module is simply a place where you can store methods.

Thus, you can include a module as a mixin in a class, and it will get
all the methods.

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?

It depends what you want to do - do you need to use the superclass
separately?

Julian

Learn Ruby on Rails! Check out the FREE VIDS (for a limited time)
VIDEO #3 out NOW!
http://sensei.zenunit.com/

On 09.04.2008 07:32, Shin guey Wong wrote:

class?
If you need to instantiate it make it a class. Everything that could be
viewed as an “item” should probably be a class (where “item” could as
well be a complex algorithm, see “command pattern”). A module on the
other hand is more like a container for functionality that can be used
in multiple places. It can be either completely independent or - more
common I believe - rely on some other methods for interfacing (like
Enumerable relies on #each being defined). Just look at modules defined
in the standard library to get an idea how they are used (for example
Comparable, Enumerable).

Kind regards

robert

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shin guey Wong wrote:
| Julian L. wrote:
|> A module is simply a place where you can store methods.
|>
|> Thus, you can include a module as a mixin in a class, and it will get
|> all the methods.
|>
|
| 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?

Yes. :stuck_out_tongue:

It depends, actually. A module provides a namespace, and (ideally)
prevents namespace collisions.

It also provides grouping of classes (well, d’uh. I’m amazed at my
insightfulness at this early hour…).

Let’s say you have an application, which brings its own String, Math,
and Array functions. If you put them into the Module MyApplication, you
prevent collisions with Ruby’s String, Math, and Array functions.

Additionally, you can mixin these methods, while maintaining the ability
to inherit from the classes you have in your modules, if need be.

(You can inherit from Digest::MD5, for example.)

Also, only a module can include a module.

In short: It depends on your scenario.


Phillip G.
Twitter: twitter.com/cynicalryan

Make the coupling between modules visible.
~ - The Elements of Programming Style (Kernighan & Plaugher)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf8WtgACgkQbtAgaoJTgL8CZACgk0bY83eL9DX8JZExeXfBJfs+
xpkAnibP1+clUdU5ii7Dzv1UAvZPLzL6
=5zTq
-----END PGP SIGNATURE-----

On Apr 9, 7:32 am, Shin guey Wong [email protected] 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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs