Something that we’ve noticed on the project I’m working on at the moment with respect to the single responsibility principle is that often classes start off adhering to this principle but as soon as changes come along that single responsibility is pretty much ruined. It often seems like a new piece of functionality fits quite nicely onto an existing object but then when we look back on it in retrospect it didn’t really fit that well and then another bit of code that fits even less well is added and an object is carrying out 3 responsibilities before we know it. One way to potentially get around this is to write the responsibility of a class at the top of the file so that hopefully people will read that before adding anything new. In a recent coding dojo we were reading through some of the Jetlang code and that approach is followed on a lot of the classes which has the added benefit of making the code easier to follow if you’re new to the code base.

Uncle Bob talks quite a lot about ensuring that we design flexibility into the areas of the code that are likely to change so that if we do have to change the code then we can do so easily. I’ve read this type of advice before but I’m never sure how exactly you know where those areas of change are likely to be unless you’ve worked on a similar system before. From what I’ve seen any code which relies on another system’s data/representations needs to be designed in this way as we don’t know when it is going to change and it might even change without much warning so we need to adapt to that situation fairly quickly.

He didn’t mention the Interface Segregation Principle in this presentation but I find this one the most interesting, probably because I haven’t seen it followed on any projects I’ve worked on yet and I’m intrigued as what a code base that followed it would be like to work on. I like the idea of having role based interfaces although I imagine it would probably be quite easy to abuse this principle and end up with interfaces that are so finely grained that we lose the domain’s meaning.

While I have no doubt that if we followed these principles all the time when coding our code base would probably be much cleaner, it feels to me that these principles are quite difficult to remember when you’re coding. From what I’ve noticed we find it much easier to follow ideas like Don’t Repeat Yourself, perhaps because it’s easier to see when we are breaking principles like this. In addition, most people tend to agree about what makes repetition of code but when it comes to something like the Single Responsibility Principle, for example, people seem to have different opinions of what a responsibility is which makes it difficult to get consensus. I quite like the newspaper metaphor to writing code which Uncle Bob describes in Clean Code and he elabroates on this further in a recent post about extracting method until you drop. I find ideas like that easier to follow when coding. My current thinking is that the principles are really good for when we’re analysing code having taken a step back but when we’re actually coding they’re not necessarily always the first thing to come to mind, at least for me! Perhaps that’s normal but I’m intrigued as to whether more experienced developers than me are able to keep these ideas in mind all the time?