“A class should have only one reason to change.”
Every class exists for a specific reason. When you design a class- its essential that you know what that reason is and you know it well. And that reason should be the only reason that the class exists and there should be no other reason for that class to exist.
Lets start by some examples
e.g. We have a class OrderValidator. Now this is a class which is written to validate an Order.
Now this class shall change only when a validation rule changes- and not for any other reason
If we change the name of the column in the table in the Database and you have a direct impact on this class- you are not following the Single responsibility principle
If you change the client from web to a desktop based swing client- and you feel the need to change this class. You are violating the Single responsibility principle
Another example – You have a class which sends a message to an external system.
This class should change only when the communication mechanism changes. Like you are adding more capabilities to send messages in different formats or via different channels.
If the message generation logic changes and you need to change the class which sends the message- you are guilty of violating the Single responsibility Principle.
But why do we have Single Responsibility Principle?
-More the reasons to change a class- more often will that class change. This will give rise to greater opportunities for defects to creep in.
-The more a class does- more complicated it will be and hence harder to maintain in the long run.
How do we enforce it ?
- Keep your classes concise. If you need to accomplish two tasks- write two classes. Don’t be shy about writing multiple classes. Number of classes doesn’t increase complexity as would by overloading the same class with multiple tasks.
- Good communication.Put the objective of the class on top of the class to remind yourself (and the poor souls who will work on the class after you are long gone) – what the objective of the class is.
Many times the class looses its objective- simply because it was not well communicated to all.
- Ask yourself questions. What all situations will warrant a change to this class? What can change in the requirements that I will have to revisit and change this class ?
What causes this rule to be broken ?
-Shortcuts.Often a developer feels too lazy to write a new class and would rather add another rmethod to the same class. A class may have had a specific purpose when it was written- but over time things might get muddled. As more and more people contributete to the project- each may not understand exactly what the purpose wa and may see the class in a different light.
-Ill-defined responsibility for the class. When the class is first conceived- that is the only time its responsibility is decided and it should be well defined in clear terms. and that reason should be embedded as comments on top of the class for all to see and honor.
But…
“I dropped a column from the table and now I have to change the Validator,the DAO layer, UI layer”
That’s OK. This principle doesn’t prohibit that a single change can cause multiple classes to change
If you have dropped an attribute from the Model- you have basically dropped the validation referring to that attribute. And since its a change in the validation- its OK to change the OrderValidator.
Finally…
As always- Single Responsibility Principle is a guideline for writing robust class. Not the law.There will be exceptions- always.
So who do I thank for this down-to-earth principle?
http://en.wikipedia.org/wiki/Tom_DeMarco
Good Luck !!!
-
Jagdish Salgotra
