Mark Needham

Having just flown half way across the world from Sydney to London I’ve been thinking about how airport security is done and noticed a somewhat interesting link to the use of null checks in code.

In Sydney and Dubai airports my baggage and I were scanned only once  before I was able to get onto the plane. I wasn’t scanned again when I went to the departure gate nor when I got onto the aircraft.

Yet I often see code which has null checks peppered all over the place – in fact in some code I’ve seen there were null checks before every single call on an object. Not only does it make the code look extremely ugly, but a lot of the checks were completely pointless since there was no chance of the object being null anyway.

Imagine how annoyed we would be if they checked our baggage at every single step from entering the airport to getting on the plane! So let’s cut out unnecessary null checks!

One of the major learning points this week at TWU has been understanding when it is appropriate to use inheritance and when delegation is the better choice.

I had heard stories about how inheritance could be misused but I didn’t think I would be stupid enough to fall straight into that trap! We were taught the concept using ‘Measurement’ as the problem domain. So to translate the previous sentence into English: The aim was to design classes which could handle old school measurement types such as Inches, Feet, Yards, and so on.

I went about the task by first creating a base Measurement class and then created Inch, Foot and Yard as sub classes of this. The code looked pretty slick to me and I was quite pleased with how it had turned out. I was feeling pretty confident that I had nailed the objective of the session. Alas, it was not meant to be!

Upon reviewing the code my partner and I had created, one of the trainers pointed out that the sub classes did not actually do very much at all. They were effectively useless classes and there was barely any difference between them! One of the other requirements for the code was that it should be possible to compare an instance of the Inch class with an instance of the Foot class, an instance of the Yard class with the Inch class and so on. No problem I thought and promptly created methods called ‘ConvertToFoot’ in my Inch class and ‘ConvertToInch’ in my Foot class.

One of the cardinal sins of object orientated programming had been committed! I now had 2 methods which did almost the exact same as the other for no additional benefit. What if there were 100 different measurements? That would mean 99 different conversion methods each to convert to all the other types of measurement. Clearly not an optimal solution – I had taken the bait and fallen into the trap of over use of inheritance.

Anyway, the lesson of the session was that in this particular case it was better to use delegation or composition. In this example it means that there is only the need for one Measurement class, each instance of which comprises of a Unit object. The concept of a ‘slug’ was introduced – no not one of those nasty little insects, but in this case meaning an instance of an object with a private constructor and one public static instance. In other words slugs are like a poor man’s Singleton. The code looked something like this:

This made it far easier to add future measurement types, and meant that only two classes were needed instead of a potentially infinite amount.

I read an interesting article on this topic by Robert Martin, titled ‘Template Method & Strategy: Inheritance vs Delegation’ which explains the reasoning much better than I have here along with a code example.