Jump to content
  • Advertisement
Sign in to follow this  
Dom_152

Alternatives to multiple inheritance

This topic is 3540 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was thinking about a design whereby a class can be "extended" with functionality implemented in separate classes. For example Graphics and Sound functionality would be implemented in separate classes and then other classes can inherit from one or both based on its requirements. This is an alternative to having the Graphics and Sound classes as data members in the other class. I was wondering if there are any other alternative methods to what I just described (barring object composition which I basically mentioned there)

Share this post


Link to post
Share on other sites
Advertisement
... Well, don't you like object composition? How many options were you hoping for? There are really only three ways that data gets incorporated into an object: being listed directly as a data member, indirectly via a member (or "virtually" by a member which is a handle to some other object not actually part of the class), or indirectly via a base.

Share this post


Link to post
Share on other sites
I can imagine a language capable of dynamic multiple inheritance, which I think would be pretty cool. Then you could say, at run-time, I'd like a Ball class derived from my Physics, Jello-Ball, Sound, and Graphics classes.

Share this post


Link to post
Share on other sites
Quote:
Original post by Dom_152
I was wondering if there are any other alternative methods to what I just described (barring object composition which I basically mentioned there)


1. Traits
2. Mixins
2.5. I saw on hacker news that "why" (you'll probably only be familiar with him if you use Ruby much) has a little language called potion that has scoped mixins. You might be interested.
3. "components"
4. If your language has duck-typing you don't need inheritance anywhere near as much

Share this post


Link to post
Share on other sites
Quote:
Original post by the_edd
1. Traits


Which are typically just inheritance using some interesting template magic to avoid run-time overhead when only compile-time polymorphism is needed.

Quote:

2. Mixins
2.5. I saw on hacker news that "why" (you'll probably only be familiar with him if you use Ruby much) has a little language called potion that has scoped mixins. You might be interested.


Which are basically just a special case of the multiple inheritance approach.

Quote:
3. "components"


Which as far as I've ever been able to tell are just a rebranding of aggregation/composition.

Quote:
4. If your language has duck-typing you don't need inheritance anywhere near as much


True; ad-hoc polymorphism is a very nice thing. :) But that still leaves open the question of how to leverage *existing* functionality; while you may save tons of boilerplate otherwise needed for declaring interfaces, you still have to provide implementations.

Share this post


Link to post
Share on other sites
Quote:
Original post by jdindia
I'd like a Ball class derived from my Physics, Jello-Ball, Sound, and Graphics classes.

That's not what inheritance is. I have never heard of a Ball that IS-A Sound.

Share this post


Link to post
Share on other sites
Inheriting is similar to having, except you gain access to protected members and maintain a superset of the base's interface. Because there is no other way to have access to protected members, and no convenient way to have an identical interface, there is no true alternative, in my mind.

Share this post


Link to post
Share on other sites
Quote:
Original post by DevFred
Quote:
Original post by jdindia
I'd like a Ball class derived from my Physics, Jello-Ball, Sound, and Graphics classes.

That's not what inheritance is. I have never heard of a Ball that IS-A Sound.


Although it's not true that a Ball Is-A Sound, if you were going to use multiple inheritance to implement this scheme, it still might make sense. In this particular case, the 'Sound' class would probably really be 'ThingThatMakesSound'. I'm not claiming this a good solution (it's really just turning into composition and MI is just going to make things confusing...). But it's worth pointing out the naming of the classes in this scenario is likely to be different from their actual semantics (if only to keep the class names simple and straightforward)...

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Quote:
Original post by the_edd
1. Traits


Which are typically just inheritance using some interesting template magic to avoid run-time overhead when only compile-time polymorphism is needed.


Their purpose isn't just to avoid overhead. You can really extend the functionality associated with a class without touching its definition.

Quote:

Quote:

2. Mixins
2.5. I saw on hacker news that "why" (you'll probably only be familiar with him if you use Ruby much) has a little language called potion that has scoped mixins. You might be interested.


Which are basically just a special case of the multiple inheritance approach.

The kind in potion aren't, if I understand them correctly. You could kinda maybe sorta lump them in the the same basket, but these mixins don't touch the "class" definition in the traditional sense.

Quote:

Quote:
3. "components"


Which as far as I've ever been able to tell are just a rebranding of aggregation/composition.

True, but is it not a valid alternative?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!