Multiple inheritance is bad?
I'm implementing a simple game, and I have a trouble with class architecture.
Assume that you implement a object class, and you want to separate some feature.
For example, some objects have a power, some objects have a life. and some objects have several feature. If you want to have a power and life both, you have to inherit two class.
If each class is an interface, you need member variables for power and life. because an interface can't have a member variable, even if it's possible in cpp.
and you have to implement setter and getter in each class. because an interface can have only pure virtual functions.
If each class is not an interface, you don't need to declare member variables for power and life. but it is a multiple inheritance. many people say that a multiple inheritance is bad.
What is the better way?
Assume that you implement a object class, and you want to separate some feature.
For example, some objects have a power, some objects have a life. and some objects have several feature. If you want to have a power and life both, you have to inherit two class.
If each class is an interface, you need member variables for power and life. because an interface can't have a member variable, even if it's possible in cpp.
and you have to implement setter and getter in each class. because an interface can have only pure virtual functions.
If each class is not an interface, you don't need to declare member variables for power and life. but it is a multiple inheritance. many people say that a multiple inheritance is bad.
What is the better way?
Last edited on
multiple inheritance is not 'bad'. It is challenging to do well, and the modern programming way of doing things is to take away anything that remotely offers the programmer a chance to mess things up.
MI allows you to mess up by inheriting traits you did not want along with the ones you did want. C++ has multiple ways to make that a non-issue; you can over-ride the unwanted parts into local private do-nothing methods or you can use the delete keyword to do the same. So that is a non issue if you remember to do it carefully. The other issues are things like deep MI chains pulling in the same base twice or trying to unravel which version of an overload is the right one at which stage of the chain. Both will drive you nuts if your MI chain is too complicated -- but this is a design problem up front and there would be red flags all over the place before you even touched the keyboard for code.
The other reasons cited as to why it is 'bad' are what I would call eggheadery. Now you are off into theroycrafting OOP principles about whether your base classes should have been one class or not, and if not, should one of them inherit from the other, and if not, is the new derived class doing two things (because the bases were each doing one thing already, now the new one technically does two things?!). All that is kind of taking it 'too far' to me.
you have a cyborg object that has a power and a life. you have a robot object that is not alive but needs power. You have a human object that is alive but does not require power. Ok. what makes sense here: the cyborg inherits both and it works, or you tie yourself into a convoluted workaround knot to avoid it? (although in this scenario, one does wonder if the cyborg is actually better off being a human and a robot... inquiring minds want to know... nevermind..).
as for the interfaces -- use them if you need an INTERFACE. I would NOT use them as a way to avoid MI just for the sake of avoiding MI. If the MI chain is too complicated, revisit this idea though: if it simplifies the inheritance chain and has tangible rewards, then yes.
If you do chose to use MI, keep it as small as you can and only where you need it. You are correct to ask each time you consider it whether there is a better way. Keep doing that. Treat it almost like goto: its a tool that is awesome where you need it, and best avoided if you can, but don't do equally convoluted workarounds just to avoid it. I also treat it kind of like loops or logic blocks: if you start nesting more than 3 deep, stop and give it another look as to why it is so complex and how to eliminate the complexity if you can.
MI allows you to mess up by inheriting traits you did not want along with the ones you did want. C++ has multiple ways to make that a non-issue; you can over-ride the unwanted parts into local private do-nothing methods or you can use the delete keyword to do the same. So that is a non issue if you remember to do it carefully. The other issues are things like deep MI chains pulling in the same base twice or trying to unravel which version of an overload is the right one at which stage of the chain. Both will drive you nuts if your MI chain is too complicated -- but this is a design problem up front and there would be red flags all over the place before you even touched the keyboard for code.
The other reasons cited as to why it is 'bad' are what I would call eggheadery. Now you are off into theroycrafting OOP principles about whether your base classes should have been one class or not, and if not, should one of them inherit from the other, and if not, is the new derived class doing two things (because the bases were each doing one thing already, now the new one technically does two things?!). All that is kind of taking it 'too far' to me.
you have a cyborg object that has a power and a life. you have a robot object that is not alive but needs power. You have a human object that is alive but does not require power. Ok. what makes sense here: the cyborg inherits both and it works, or you tie yourself into a convoluted workaround knot to avoid it? (although in this scenario, one does wonder if the cyborg is actually better off being a human and a robot... inquiring minds want to know... nevermind..).
as for the interfaces -- use them if you need an INTERFACE. I would NOT use them as a way to avoid MI just for the sake of avoiding MI. If the MI chain is too complicated, revisit this idea though: if it simplifies the inheritance chain and has tangible rewards, then yes.
If you do chose to use MI, keep it as small as you can and only where you need it. You are correct to ask each time you consider it whether there is a better way. Keep doing that. Treat it almost like goto: its a tool that is awesome where you need it, and best avoided if you can, but don't do equally convoluted workarounds just to avoid it. I also treat it kind of like loops or logic blocks: if you start nesting more than 3 deep, stop and give it another look as to why it is so complex and how to eliminate the complexity if you can.
Last edited on
Agree with jonnin. An issue with multiple inheritance is often called the 'diamond' problem. There's loads of info on the internet about this - and with C++ in particular.
Thank you guys. I thought too that many people say something is bad, but if it is not too much, It's find likes goto.
Topic archived. No new replies allowed.