To the extent that I understand the Single Responsibility Principle, a SINGLE class must only have one responsibility.

We use this so that we can reuse other functionalities in other classes and not affect the whole class.

My question is: what if the entity has only one purpose that really interacts with the system, and that purpose won't change? Do you have to separate the implementations of your methods into another class and just instantiate those from your entity class?

Or to put it another way... Is it ok to break the SRP if you know those functions will not be reusable in the future? Or is it better to assume that we do not know if the functionalities of these methods will be reusable or not, and so just abstract them to other classes?


One formulation of the SRP is: Every class should only have one reason to change.
The reason behind this is, that requirements are almost certain to change at some point in the future - probably the least convenient one.

When you use one class to implement two separate functionalities, you are risking to run into a situation, where the requirements for either functionality change and the two requirement sets as well as your design decision to not keep their implementation apart can no longer be reconciled. That's the last call for applying SRP and refactoring the one class into two (or more), before you start bending your code around a design flaw.

But seriously, just get it right the first time. All the time you waste speculating on whether it's safe to violate SRP based on your prognosis on future requirement changes (which is something programmers really just suck at), use it to create two classes. It's a trivial thing to do, that most IDEs will even do for you.

| improve this answer | |

Your assumption that you might know that functions won't be reused is incorrect. You cannot know who will want to use your classes or how they'll want to use them. Therefore you should always assume that your class will be used by someone else in the future and stick to good design principles.

If nothing else when you revisit the code in 18 months time you'll be able to work out what you were attempting to do when you wrote the code in the first place.

| improve this answer | |

Unit tests can be considered as reusing a class.

Therefore, SRP improves testability.

| improve this answer | |
  • @downvoter: care to explain? – Sjoerd Nov 11 '11 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy