I recently came across a very interesting podcast about SOLID principles and wanted to write a very brief blog entry regarding one particular principe. The Single Responsibility principle which is the S of SOLID.
Sometimes, even experienced developers seem to forget about some OOP basics and one of the most common behavior I have seen is the lazyness (or something else… don’t know) to correctly name a class, a namespace or a project. Have you ever seen someone adding an Utilities project? Or another developer creating a “Helpers” namespace that contains “Helper” classes…
Well, if you look at these classes, they usually contain everything and their opposites. While I agree that finding good names is not always straightforward, I admit that my hair stand when I come across such classes or, worse, whole projects because it is the starting point for the mess… “I could not find a container for my method, I put it in the XYZHelper class. After all, it helps achieving a goal, so it pertains to a helper class. I never came across a HELPER namesace or class in the whole .NET framework even though, there are helper methods which are not isolated in a helper class).” 🙂
The Single Responsibility principle helps to solve this common issue. Simply, check your class and find out what are the reasons that can make it change. If you found more than one reason, then, you should split it into two or more classes. And once split, the name of the new classes is more obvious because you have split the methods into subsets based on their responsibilities which makes them have something in common (which is generally a good starting point for naming a class).
That’s the S principle (very simplified).
For more information, check out the podcast on this link: http://www.hanselminutes.com/default.aspx?showID=163