Danny Dawes – Noirenex Designs

Hey folks,

I know for many of you, this is a bit old hat and for experienced developers, it’s a standard and not something anyone consciously thinks about, but it is worth a blog to talk about.

After reading a very interesting article on mocks and stubs while contemplating dependency injection and Castle Windsor (From http://codebetter.com/, well worth a bookmark, this article), amongst other things, it got me thinking about Polymorphism and how I was taught it at university. The problem I have is that the way in which they teach polymorphism (At least how I was shown) is very simple, and difficult to sometimes realise in an enterprise application.

Some of you will be familiar with the concept of having an Animal interface, IAnimal, with a method ‘MakeSound’, and a series of classes that implement IAnimal that have difference implementations of MakeSound, for example a Dog class that returns “Bark Bark”, or a Cat class returning “Meow”. What this essentially allows you to do is create methods in other classes that accept an object that implements IAnimal, and then perform operations on that object, without really needing to know the actual animal type itself.

You could apply this thinking to something like a rubber stamping machine, the stamping machine has a slot for a rubber stamp that is of a fixed size, and is able to use that stamp to make pictures, it doesn’t need to know about the picture of the stamp itself, as long as it can use it to stamp, so on the stamp, we might have a MakePicture method that’s called by the stamp machine, and that MakePicture method produces a different image depending on the stamp being used. So, we can pass in our Dinosaur stamp, which implements IStamp, to the PressStamp method of the machine, and it produces a nice stamp of the dinosaur.

Now, if we extend this a little further, we can see where the flexibility comes in, the stamp itself could have a property of type ‘Material’, this could be an interface and have subclasses of Rubber, Metal, Potatoe and influence how the texture of the impression is handled when calling MakePicture, by calling Material. ApplyTexture while printing, it could also be used to influence how quickly the integer ImpressionsLeft is depleted, based on the amount of paint applied.

Next, if we give some thinking to how this can be applied to testing. If we’ve programmed our classes to interfaces, it means we can pass in mock objects to testing methods and get a real result based on interaction with that object, we can also have in-memory storage instead of writing to the database, so that we can test the connection to the database separately.

Hopefully what I’ve outlined above gives you a flavour of what it is and helps you to see how it can be applied, coding in this way does inevitably increase the initial outline time in development, especially if you’re doing test driven development, but when you’re writing medium to large scale applications, having a flexible and extensible core in place will save headaches down the line.

As an afterthought, I would perhaps add one small caveat, in that, if you do start looking at applying more intelligent or complex designs to your solution, please, please, make sure that you 1) Document it and have someone else go through it to ensure it’s comprehensible and 2) Ensure anyone who might be working with you is fully up to speed on the techniques used. The reason for this is because I have seen a couple of systems butchered into submission because the original architecture wasn’t understood, I appreciate that the technologies used can be old, but quite often, if it is well engineered, swapping classes out and creating new ones isn’t all that bad, as long as they understand what’s going on. I’ve seen some applications that have 4 different layers for getting data, using ORM, sprocs, straight SQL connections and table adapters & data tables, this leads to complications and conflicts, and quite often the new layers put in circumvent important business logic.

So, make sure you document it, and make sure the documentation can be understood.

Remember, I’ve only been in the field 3 years as of writing, so, if anyone has anything to add to this, feel free to add it into the comments and I will amend if needed, but I hope you get the general idea