Let’s hope my readers also read the comments.. I wouldn’t want my post to make people stop applying good design principles. As with most techniques, especially so within agile, one should apply them fully to start with – the way the masters describe them based on their experiences – and then later figure out as one go what works best for oneself in specific cases.

On the other hand I find some principles fundamental. I am passionate about readable and maintainable code. I have seen quite a lot of the opposite in my years as a developer, and know how hard unreadable code is to maintain. Some principles have to be applied to some degree at all times in order to write understandable code.

Creating classes with several distinct and different responsibilities often creates a distinct smell of unreadableness. To prevent this smell Robert Martin talks about, among other things, SRP. I like to talk about cohesion. Cohesion is about placing logic where it belongs, and being able to find it when you need it. I think SRP is a great principle to get higher cohesion. I split my classes if they are getting hard to understand, and they tend to be hard to understand when they have too many responsibilities.

When it comes to the Solid-principles:

The problem with the Solid-principles these days is that people seem to think that those are the five only true principles of design. First, There are many others and IMHO also a few more fundamental and important principles than the Solid-principles. Second, I do not actually find all five of the Solid-principles that important in my daily work. I love SRP for maintainability (and I focus on cohesion all day long). I use DIP daily for testing. Sometimes, when I feel really clever, I use OCP. But when it comes to LSP I think a more important principle is “Be very skeptical of inheritance all together”.

- Tore Vestues

Btw I agree with the last sentence 1000% and that is the reason why I would not easily write a post suggesting that developers perhaps should not follow the principles. I believe when the developers are mature enough to see that violation is better then following a principle that then they are mature enough to decide not to follow it. The problem usually is that principles are left behind because the developer doesn’t really understand it.

You don’t write code without a test. You don’t refactor without a need. You don’t apply the patterns without a violation to a principle that you have discovered through some change you had to do to the code because of a test.

But since developers usually apply too few of the principles, I understand why this hasn’t been the focus in the lectures and articles I’ve seen so far.

I believe that most developers ‘really’ don’t need to worry about following to many principles, usually it is the other way around. Also there are so many more principles than just the 5 SOLID principles, so I am absolutely not saying you should always follow everything, that is not even possible (they often contradict each other). But applying the SOLID principles is something that I believe you should just do, especially OCP, DIP and SRP.

Of course there will be exceptions, “the exception confirms the rule” right? Also there are different gradations of applying the principles, especially with SRP. You can absolutely go crazy with defining a single responsibility, don’t do that. But if a class is doing it’s own data access, logging and order tracking then I think it does to much, three classes there for sure.

And you know what the beauty of this all is that it helps you on all fronts, there are many benefits from applying proper design principles: Testability, Re-usability, Clear intend and Easier Maintainable.

P.s thanks for the link, and sorry for the non Norwegian reply :)

-Mark