The Dangers of Hammers (or, Why SRP Isn’t Dangerous)
If you haven’t noticed, David Cooksey and I are having a bit of a back-and-forth about the Single Responsibility Principle and its use (or misuse) in software development. And I’m obviously not here to talk about the dangers of hammers. But as David Cooksey has come up with another example of how SRP (the Single Responsibility Principle) is dangerous when completely misunderstood, I figured I had to reply with something.
I’m not going to spend any time discussing the code in his latest example, as I don’t think there’s anything new to discuss. It’s just another “wrong-headed-application-of-SRP-causes-bad-code” post.
I guess we both agree that many people don’t necessarily understand SRP correctly (and, honestly, I’m sure I don’t always apply it perfectly every time I try either). However, it feels to me that David wants us to fear using SRP, and I want to try to help people understand how to apply it properly.
Rather than continue to rehash what SRP means to me, I’d like to defer to those from whom I’ve learned and point you at some good articles on SRP, The Open/Closed principle, and other SOLID topics in the hopes that you can see past the fear and start applying these powerful tools properly and without fear.
Jeremy Miller (of StructureMap fame, if you don’t already know) wrote a nice article in the June 2008 MSDN Magazine entitled The Open Closed Principle, in which he also talks about SRP. In his words:
The point of the Single Responsibility Principle isn't just to write smaller classes and methods. The point is that each class should implement a cohesive set of related functions. An easy way to follow the Single Responsibility Principle is to constantly ask yourself whether every method and operation of a class is directly related to the name of that class. If you find some methods that do not fit with the name of the class, you should consider moving those methods to another class.
I highly recommend reading his article in its entirety (as well as about anything else I’ve ever read that he has written), as I’m pretty sure that article is the subconscious inspiration for my refactoring of David’s original post.
Another good reference is the originator of the grouping of principles we know as the SOLID principles, Robert Martin. In his post “Getting a Solid Start” “Uncle Bob” says:
Following the rules on the paint can won’t teach you how to paint
This is an important point. Principles will not turn a bad programmer into a good programmer. Principles have to be applied with judgement. If they are applied by rote it is just as bad as if they are not applied at all.
Having said that, if you want to paint well, I suggest you learn the rules on the paint can. You may not agree with them all. You may not always apply the ones you do agree with. But you’d better know them. Knowledge of the principles and patterns gives you the justification to decide when and where to apply them. If you don’t know them, your decisions are much more arbitrary.
I could make the same arguments David makes about SRP for just about any software development technique. Have you ever seen a 12-level-deep inheritance structure used to avoid a bunch of nested if statements (or, god-forbid, the 1200-line method filled with those nested if statements) when applying The Chain of Responsibility Pattern or some other form of composition would have been a much better, and more maintainable, solution. So, is inheritance dangerous? Yes, if used incorrectly.
In conclusion, hammers are not dangerous when used correctly. However, most tools are dangerous when they are misused, and thousands of people hit themselves in the thumb with a hammer every year. Hammers are dangerous - handle with care!