Re: Support for multiple Inheritance by classes

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 <[e-mail]> =
wrote:

>=20
> On Mon, Nov 5, 2012 at 6:44 PM, Marc Heiler <[e-mail]> =
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/