S in SOLID - how/where do you draw the line? [closed] - solid-principles

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
So, single responsibility principle - class should change for one and only one reason but how do you effectively judge what that responsibility really is. Simple example:
public class UserManager
{
public void AddUser() { }
public void RemoveUser() { }
public void UpdateUser() { }
}
It can be argued that that any one of these would break SRP. So you end up using DI for two of them and end up with this:
public class UserManager
{
private UserRemover _remover;
private UserUpdater _updater;
public UserManager(UserRemover remover, UserUpdated updater)
{
_remover = remover;
_updater = updater;
}
public void AddUser() { }
public void RemoveUser() { }
public void UpdateUser() { }
}
What if there are more methods pertaining to user management? Would go down that road and keep on passing additional dependencies in a constructor? For any class having more than one public method it can be argued that it breaks SRP. Do you use common sense and go with option one or be purist and go with option two?

Answer 1

Single Responsibility Principle
A. What is the responsibility of UserManager?
What do you do when you update a User?
What do you do when you remove a User?
What do you do when you add a User?
If the methods are plain simple, they don't do MORE than to update a user in a DB. Than the responsibility of UserManager may be UserRepository, perhaps.
Or Maybe the responsibility of UserManager would be more like of a list of users. If you look at List object. Does it use many other sub classes? no. If this is your situation, you should rename UserManager the UserList object.
The main reason why you are unsure about the SRP principle in this situation is because the word MANAGER doesn't mean anything specific. Try to find a better name and you'll find your answer. It'll show up in the name if your class needs to access more specific objects.
Also, Your unit tests should help identifying the problem. Unit tests are a good way to reveal that kind of mystery.
Also, no purist would over architect that kind of problem ;) Remember, Premature Optimization is the root of all evils.