The meek shall inherit?

Sorry for the pause … Making a living can interfere with life at times.

Every COBOL programmer out there knows that the most important thing about Object Oriented Programming is inheritance, right?  To us old procedural programmer’s it just sounds so cool! I remember when I first started reading about inheritance in OOP I thought it was the answer to most of our programming problems.  Increasing complexity of existing code could be handled by simply inheriting code already written without breaking it. Turns out I was wrong … Err, mostly!

By and large it would be a GOOD IDEA if you didn’t design new classes that inherit the classes that you write. Note the qualifications there: by and large as well as that you write! There will be times that you might have good reason to inherit but, resist the urge if you can! You will build a far more flexible and far less complex system if you do. The other qualification was that you write … You will inherit .NET Framework classes all the time. That was what they were designed for, by experts. They provide functionality that it would be foolish to re-write. If you restrict yourself to this discipline you will reduce inheritance nesting to a minimum. Your code will be more performant, predictable and easier to debug. There is nothing more confusing than trying to work out where you are in an inheritance hierarchy that is over head height!

O.K. Now I’ve said what you shouldn’t do, what the hell do you do? You certainly don’t re-write the same functions everywhere. In the .NET world there are two basic methods:  use decomposition and/or interfaces. I will come to interface programming in .NET soon. Today is about decomposition.

Let’s start thinking on the basic school system we’re working on. It’s time to introduce Teachers. On first flush you might think a teacher is just a type of Person that we’ve already defined, so let’s just inherit from the Person class. Wait a minute though … What about the Teachers who are also Parents? What about the Teacher who also is Head of English or also does some school maintenance? Remember under .NET a class can only inherit from one class …

Well, first and foremost the Teacher is a Person who has other attributes or properties, like Position and a collection of Classes they teach (we’ll get to collections and a neat feature called Generics in the next post, but you’ll see a little of them in the code I’ve put together for this post). If we look at the Teacher class:

class-id School.Data.Teacher public.

working-storage section.

01  Teacher-Id       binary-long                        as "Id"             
                     public property with no set.
01  Teacher-Person   type School.Data.Person            as "Person"         
                     public property with no set.
01  Teacher-Position string                             as "Position"       
                     public property with no set.
01  Teacher-Classes  type School.Data.ClassCollection   as "ClassesTaught"  
                     public property with no set.

method-id New.
local-storage section.
procedure division using by value teacherId        as binary-long
                                  teacherPerson    as type 
                                  teacherPosition  as string
                                  teacherClasses   as type 
    Set Teacher-Id          to teacherId.      
    Set Teacher-Person      to teacherPerson.  
    Set Teacher-Position    to teacherPosition.
    Set Teacher-Classes     to teacherClasses.                        

end method.

method-id ToString public override.

procedure division returning returnString as string.

Set returnString to String::Concat(Teacher-Position ", " 
                 Teacher-Person::Title " " Teacher-Person::LastName).

end method.

end class.

You can see we have decomposed a Teacher into an Id, a Person, their Position and their ClassesTaught. Simple to write and simple to understand! We can enhance the underlying logic in the Person class without breaking the Teacher class and similarly do the same for the Teacher class. We can create Unit Tests for the Person and Teacher classes (using a technique called mocking) independent of each other and be confident in the functionality of each without worrying about dependencies.

If you are interested in some of the finer, more technical points of the argument of choosing composition over inheritance you might like to check out this article at StackOverflow (an excellent source of .NET wisdom) or perhaps this article at Wikipedia.

You can have a squizz at the code built so far here.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: