Using Multiple Inheritance for Good

Multiple inheritance sounds like a good thing. After all, why would you not want to inherit a bunch of stuff? But some programmers don’t like it. They say it makes things confusing, they say that a class made from multiple parents will be neither one thing nor the other. And mostly I think they are right. However, when the alternative is something even more confusing, I can be persuaded to think of multiple inheritance as a good thing.

My problem was that I wanted to make a driver class to control a Furby toy over Bluetooth BLE from an ESP32. The ESP32 has a bunch of Bluetooth libraries and they work fine, but they expose their callbacks the form of class instances that contain overridden versions of the class callback methods. Ugh.

Wow. That sounded cool didn’t it. But did it make sense? Probably not. Here’s the thing in bullet points:

• When a program connects to something over Bluetooth BLE it needs a way that the Bluetooth BLE library can tell it things. In other words, if the BLE library receives a message from the Furby it needs to be able to deliver this to the program.

• One way to do this would be to pass the Bluetooth BLE library a reference to a function for the library to call when the message arrives. I like this method, lots of other things use it. However, the BLE library doesn’t. For some reason it likes to be given a C++ class instance.

• A class is an object that can contain methods (lumps of program code a name). If I pass the Bluetooth BLE driver a reference to the object the driver can then call the methods in it.

• The Bluetooth BLE library provides templates in the form of abstract classes (classes with method names but no implementation) which I can override with my own methods in new message passing classes that I base on the abstract parents. I then pass references to instances of these message passing classes into the Bluetooth BLE driver so that it can call the methods in them and tell my program things. But this is a right pain, because if I want these methods to interact with the data in my program (which I do) I have to make these objects aware of their context. Which is a mess.

I hope that’s cleared that up. Anyhoo, rather than implement lots of message passing classes and then pass references around between them (ugh), or make everything static so that everything can see everything (double ugh) I simply make my Furby adapter class inherit from all the abstract BLE library message classes and then drop the overridden methods from these classes right into my driver class. Because the methods are now inside my driver they can use all elements inside the driver and it just works. So, a good use for multiple inheritance. Yay!

Unfortunately, the Bluetooth BLE driver writers have thrown in some function references too, which means that I need some static members in my driver class, but I’m in a happy place at the moment.

One of the things that occurred to me as I was writing the code was how much effort I would have had to put in to avoid using multiple inheritance. When you are programming it is important to remember that the final outcome should be a program that solves the problem. Worrying to much about the “right” way to do that can sometimes send you backwards if you are not careful.