27: Multiple Inheritance. Often Banned.

C++ gives you the power to do great things and multiple inheritance is one of the most powerful tools you’ll have. This doesn’t mean that you should always use it. Use it when it’s the right tool for the job just like any other tool. I’ll show you in this episode how to use multiple inheritance properly. One of the biggest examples of why multiple inheritance is bad is the dreaded diamond. As long as you’re aware of this problem, it’s not really a problem anymore and you should be fine. That doesn’t mean all your designs should involve base classes that get included multiple times. I tend to have the best results when I avoid the diamond entirely. But there are times when it’s perfectly acceptable as long as you use virtual inheritance. You also learn about a common application of multiple inheritance that can also lead to problems. This time the problem is just that you end up with a lot of classes. The point I make though is that a lot of classes might be exactly what you need. With multiple inheritance, you can decide. When all you have is single inheritance and some interfaces, then the language has already made the choice for you. Listen to the full episode or read the full transcript below. Transcript Imagine a carpenter telling you how he broke his leg once falling from the roof of a house when the hammer slipped that he was using to support his weight. Ever since then, he banned the use of hammers from his entire crew. The crew members now have to use wooden blocks to push nails into the boards so that they won’t be tempted to try using hammers to hang upside down. Ridiculous, right? This is clearly a case of using the wrong tool. It wasn’t even an accident. It’s not like the carpenter hit his thumb while trying to nail something. Multiple inheritance is often used wrong and because of that, some languages have banned multiple inheritance completely. Developers who only know C# or Java might even think that multiple inheritance is bad, something that should be purged from existence. Here, have these wooden blocks instead. They’re so much easier to use! The strange thing is that these languages that pretend to ban multiple inheritance still allow you to implement as many interfaces as you want. This is really just multiple inheritance under a new name and with reduced functionality. We’ll talk about interfaces in an upcoming episode. The example given most of the time for why multiple inheritance is bad is called the dreaded diamond. Let’s go back to the earlier example of a book class, a physicalBook class that inherits from book, and an audioBook class that also inherits from book. So far everything is good. What happens though when you want a new product that combines both the physicalBook and the audioBook? Well, inheritance has worked well for you so far, so you decide to create a new class called physicalAudioBook that inherits from both physicalBook and audioBook. If you draw these four classes on paper, they resemble a diamond. Use a rectangle outline for each class and put the name of the class inside the rectangle. Draw the book class on the top. Then draw the physicalBook and AudioBook classes below the book class so that the three classes so far form the points of a triangle. Then draw a line from the physicalBook class to the book class and another line from the audioBook class to the book class. These lines show relationships between classes. There should be no line between the physicalBook class and the audioBook class because they share no direct relationship. Then draw the physicalAudioBook class below everything with two lines to the physicalBook and the audioBook. The shape should now look like a diamond. The problem with this arrangement is that the book class is included twice in the new physicalAudioBook class. You can make a change so that you only have a single book class by going back to the physicalBook and aud