From: Mohammed Yasin Rahman Date: 2012-11-07T18:33:53+09:00 Subject: Re: Support for multiple Inheritance by classes --Apple-Mail=_53E1F573-CEC6-48E2-B1E2-B4527AFCBA8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I found this answer quite reasonable from this book: = http://ruby.learncodethehardway.org/book/ex44.html . The question of "inheritance vs. composition" comes down to an attempt = to solve the problem of reusable code. You don't want to have duplicated = code all over your code, since that's not clean and efficient. = Inheritance solves this problem by creating a mechanism for you to have = implied features in base classes. Composition solves this by giving you = modules and the ability to simply call functions in other classes. If both solutions solve the problem of reuse, then which one is = appropriate in which situations? The answer is incredibly subjective, = but I'll give you my three guidelines for when to do which: Avoid meta-programming (multiple inheritance) at all costs, as it's too = complex to be useful reliably. If you're stuck with it, then be prepared = to spend time finding where everything is coming from. Use composition to package up code into modules that is used in many = different unrelated places and situations. Use inheritance only when there are clearly related reusable pieces of = code that fit under a single common concept, or if you have to because = of something you're using. However, do not be a slave to these rules. The thing to remember about = object oriented programming is that it is entirely a social convention = programmers have created to package and share code. Because it's a = social convention, but one that's codified in Ruby, you may be forced to = avoid these rules because of the people you work with. In that case, = find out how they use things and then just adapt to the situation. On Nov 6, 2012, at 10:04 PM, Robert Klemme = wrote: >=20 > On Mon, Nov 5, 2012 at 6:44 PM, Marc Heiler = wrote: > There is one thing that is however not looked at much at > all in this discussion - less the distinction between > multiple inheritance vs. module mixins, and much more so > what the distinction class vs. module actually serves. >=20 > Because I often feel that the distinction between classes > and modules is much more arbitrary than seems to be reasonable. >=20 > The difference between class and module in Ruby is > - classes can be instantiated, modules can't > - classes can be inherited (SI), modules can be included (MI) >=20 > Did I miss any? Other than that both are identical (e.g. both can be = used as namespace). For me the more dramatic difference is actually the = first one because despite the differences between SI and MI in Ruby it's = just gradual (i.e. the number of items to inherit from - 1 for classes, = n for modules). >=20 > So if we assume for a moment that we agree on the most significant = difference then it follows quite naturally (for me at least) that = classes should be used for entities, tangible things while modules = should rather be used for capabilities (behavior). And I believe you = can see that distinction at work in the standard library: there's Array = which is a list of objects (entity) and Enumerable which is a set of = capabilities. > =20 > But why is that behaviour contained within a module? Why > could we not assume that ALL behaviour of every object > resides in an (perhaps invisible) module? >=20 > Then we could use classes the same way as modules. >=20 > I do not understand how this follows from the premise. If all = behavior would reside in modules than classes would not contain behavior = at all. But then classes and modules could not be used the same way. = What am I missing here? > =20 > Why must there be this distinction between classes and > modules in this way? >=20 > I do not think there is a reason why the distinction "must" be there. = It's just what Matz designed the language to be. I think the = distinction I was trying to make above is actually not too unreasonable. = It seems so far it has served the language quite well so far. >=20 > Kind regards >=20 > robert >=20 > --=20 > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/ --Apple-Mail=_53E1F573-CEC6-48E2-B1E2-B4527AFCBA8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

I found this answer quite reasonable from this book: http://ruby.le= arncodethehardway.org/book/ex44.html .

The = question of "inheritance vs. composition" comes down to an attempt to = solve the problem of reusable code. You don't want to have duplicated = code all over your code, since that's not clean and efficient. = Inheritance solves this problem by creating a mechanism for you to have = implied features in base classes. Composition solves this by giving you = modules and the ability to simply call functions in other classes.

If both solutions solve the problem of reuse, then which one = is appropriate in which situations? The answer is incredibly subjective, = but I'll give you my three guidelines for when to do which:

  1. However, do not be a slave to these rules. The thing = to remember about object oriented programming is that it is entirely a = social convention programmers have created to package and share code. = Because it's a social convention, but one that's codified in Ruby, you = may be forced to avoid these rules because of the people you work with. = In that case, find out how they use things and then just adapt to the = situation.


    On Nov 6, 2012, at 10:04 PM, = Robert Klemme <shortcutter@googlemail.com&= gt; wrote:


    On= Mon, Nov 5, 2012 at 6:44 PM, Marc Heiler <lists@ruby-forum.com> = wrote:
    There is one thing that is however not looked at much at
    all in this discussion - less the distinction between
    multiple inheritance vs. module mixins, and much more so
    what the distinction class vs. module actually serves.

    Because I often feel that the distinction between classes
    and modules is much more arbitrary than seems to be = reasonable.

    The difference between class and = module in Ruby is
    - classes can be instantiated, modules can't
    - = classes can be inherited (SI), modules can be included (MI)

    Did I miss any?  Other than that both are identical (e.g. both = can be used as namespace).  For me the more dramatic difference is = actually the first one because despite the differences between SI and MI = in Ruby it's just gradual (i.e. the number of items to inherit from - 1 = for classes, n for modules).

    So if we assume for a moment that we agree on the most significant = difference then it follows quite naturally (for me at least) that = classes should be used for entities, tangible things while modules = should rather be used for capabilities (behavior).  And I believe = you can see that distinction at work in the standard library: there's = Array which is a list of objects (entity) and Enumerable which is a set = of capabilities.
     
    But why is that behaviour contained within a module? Why
    could we not assume that ALL behaviour of every object
    resides in an (perhaps invisible) module?

    Then we could use classes the same way as = modules.

    I do not understand how this follows = from the premise.  If all behavior would reside in modules than = classes would not contain behavior at all.  But then classes and = modules could not be used the same way.  What am I missing = here?
     
    Why must there be this distinction between classes and
    modules in this way?

    I do not = think there is a reason why the distinction "must" be there.  It's = just what Matz designed the language to be.  I think the = distinction I was trying to make above is actually not too = unreasonable.  It seems so far it has served the language quite = well so far.

    Kind regards

    robert

    --
    remember.guy do |as, often| = as.you_can - without end
    http://blog.rubybestpractices.= com/

    = --Apple-Mail=_53E1F573-CEC6-48E2-B1E2-B4527AFCBA8A--