Include module and class inheritance? which one to choose?

Discussion in 'Ruby' started by Shin guey Wong, Apr 9, 2008.

  1. 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.
    --
    Posted via http://www.ruby-forum.com/.
    Shin guey Wong, Apr 9, 2008
    #1
    1. Advertising

  2. 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/



    On 09/04/2008, at 1:51 PM, Shin guey Wong wrote:

    > 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.
    > --
    > Posted via http://www.ruby-forum.com/.
    >
    Julian Leviston, Apr 9, 2008
    #2
    1. Advertising

  3. Julian Leviston 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?

    --
    Posted via http://www.ruby-forum.com/.
    Shin guey Wong, Apr 9, 2008
    #3
  4. 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, at 3:32 PM, Shin guey Wong wrote:

    > Julian Leviston 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?
    >
    > --
    > Posted via http://www.ruby-forum.com/.
    >
    Julian Leviston, Apr 9, 2008
    #4
  5. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Shin guey Wong wrote:
    | Julian Leviston 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. :p

    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 Gawlowski
    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-----
    Phillip Gawlowski, Apr 9, 2008
    #5
  6. On 09.04.2008 07:32, Shin guey Wong wrote:
    > Julian Leviston 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?


    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
    Robert Klemme, Apr 9, 2008
    #6
  7. Shin guey Wong

    Christophe Guest

    On Apr 9, 7:32 am, Shin guey Wong <> 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.
    Christophe, Apr 9, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    780
    Bertilo Wennergren
    Nov 24, 2003
  2. Andreas Bogenberger
    Replies:
    3
    Views:
    882
    Andreas Bogenberger
    Feb 22, 2008
  3. Ravi
    Replies:
    3
    Views:
    271
    Dan Sommers
    Apr 17, 2009
  4. David Garamond
    Replies:
    0
    Views:
    92
    David Garamond
    Jun 27, 2004
  5. Iñaki Baz Castillo
    Replies:
    3
    Views:
    142
    Iñaki Baz Castillo
    May 2, 2008
Loading...

Share This Page