An Analogy

Recently I have been thinking about software design in analogous terms to that of creating a statue (Don't ask me why, my mind goes to strange places okay). I have been thinking about how the architect of a piece of software may at some point decide to change the design, just as an artist may want to change the pose of a statue while he is creating it.

Now in a perfect world the software architect and the artist should both have an exact idea of the design they wish to achieve, and it is their goal to simply follow the design and implement it to the letter. This however, is often not the case. Each will reach scenarios where they suddenly think of a better design, and then want to change and evolve the original idea. This is as true in art as it is in software; imagine you have an idea for a fantastic pose for your statue, but as you begin moulding the piece you realise it doesn't look quite right and you think of another approach that is far more suitable

Jumping back a second I think to communicate my point more effectively I'll need to explain two terms you will come across in software engineering. The terms I am referring to are 'Coupling' and 'Cohesion'. Coupling describes a relationship between classes when they are heavily dependent on one another. They are literally 'coupled' together, changes made to one class may have repercussions in other classes, and this can then lead to disastrous consequences. In turn this then means making changes to your code can be extremely difficult.

Cohesion on the other hand refers to how well functions in a class are related to one another. So this means you have classes with specific behaviours and routines, not some class called 'GameClass' that has the AI, Rendering, Input, and Networking code all in it. You would want each of these to be in their own classes with their own specific interface. In your code you should always strive for strong cohesion, and low coupling, and you will make life much easier for yourself! (Trust me!)

So I hear you asking where the hell does my statue analogy fit in? Okay, imagine creating a statue out of clay (or Play-Doh, which ever you prefer) So long as you keep it wet, and fresh, you can pretty much bend and shape it in any way you like, you have complete freedom over how you want it to look. Think of this as a piece of software with high cohesion and low coupling. It is adaptable, and more suited to change. However while working on the statue, if you leave the clay to dry out, it becomes brittle and difficult to manipulate. Attempting to adjust the position of an arm may cause it, or other parts of the statue connected to it to break. You are forced to add more clay in an attempt to repair the damage already done, constantly applying these small 'fixes' leads to an excess of clay and a worse looking statue, just as if your software is highly coupled with low cohesion, you will try to fix problems that arise, but soon adding so much code will serve to make the program harder to maintain and understand, with the final result looking pretty shoddy.

So the morale of this story is always to strive for strong cohesion and low coupling (and don't let your Play-Doh dry out, your mum did always tell you to put the lid back on)