I'd like to talk about framing and not because I went out to the local art gallery this weekend. Adam Savage talks a lot about finding the correct framing - that is the correct outlook or way or thinking about an idea. I'd like to talk about a big reframing that has been going on with Illic. That is the difference between being and using. 

Let's think back to a previous entry where I was talking about the correct levels of abstraction with inheritance. I had been thinking of inheritance as a way to reuse code and to standardise my classes. Recently I have been reading some more books about programming when I came across the idea that inheritance is the highest coupling possible. If you start thinking about your code like that well… isn't inheritance actually a bad idea? Coupling is what feeds refactoring loops and problems. Furthermore, multilevel inheritance can make it very difficult to find where the actual implementation of something is. Not to mention that if you have a bad inheritance boundary it can be… anywhere? So inheritance is also bad for readability and increases cognitive load!?!? This is where the thought “use rather than be” came to me. That is if you can ever use a menu rather than be a menu… use the menu. Even better if you can use an abstract base class. You can make better use of the inheritance if you can switch out anything which implements the standard imposed by the base class. So why would you inherit from a menu that displays objects through an interface when you could just… you know display an object through the menu? In my case I think it was because I had this idea where fewer classes were better. Thus I made all of these menu maker classes which had 5 or 6 levels of inheritance creating a rats nest of coupled code which broke constantly for arcane reasons. So as I look back exhausted over my code I think to myself. Isn’t this the most basics of basics? This is where I need to take a deep breath. I think when you regret something like this you are losing empathy with yourself in the past. When I wrote these classes I didn’t even know where to look for the right answers. When I worked on them more recently I made them better and now I am making them better again. Let’s just be happy to improve.

So what do we want to do? We want to make reusable components which can be reconfigured and changed in isolation. Or to think of it another way you want to make your system out of Lego bricks. Lego bricks are small and fit together nicely. Then can easily be reconfigured - but not in arbitrary ways. Everything fits together nicely and allows you to exercise your creativity. No one wants a single block the size of a fist that doesn't quite clip onto other bricks. If it is a big single piece it better be the bottom of a cool ship - one that allows it to float in their bathtub.

So should we still use inheritance? I believe so, coupling in and of itself is not a bad thing. Besides, inheritance can help us keep making standards - think of how lego blocks all have the same studs on them to help them connect to other blocks. So how should we use inheritance? Well I believe the answer is… Mixin classes. Small classes with some defined functionality that you can inherit from. The important part is that these mixins have a definite identity and aren't too big. An example of this is my InputUI class which defines everything required for a UI element to keep track of whether it is visible and use a tweenable UI (custom tweening class). By using it I save a lot of boilerplate code and a lot of tests. In our lego example it is like how fancy lego blocks will resemble simpler blocks but still have uniform studs on them.

Which reminds me of one problem with this in C# - which is that we can only inherit from a single concrete base class. So why we may be able to use lots of interfaces to this effect in practice causes a lot of duplicated code. I think this might be another reason why I ended up with lots of inheritance. Which brings me to one last point. Sometimes it’s okay to have duplicated code. Sometimes two things will be similar and have essentially the same code in some places but are not the same. There will always be tradeoffs between coupling and code reuse which have to be made on a case by case basis. The reduction of code reuse is not the be and end all. In Lego terms not all sets need to be 3 in 1. Sometimes people just want a Millennium Falcon.

(Does General Grievous ruin my point?)

Until next time.