Menu
Suppose we are designing a UserServiceImpl class which does CRUD (Create, Read, Update, and Delete) operations. In my view Create, Read, Update, and Delete are four reasons for a class to change. Does this class violates Single Responsibility Principle? If it violates,
then should we have four classes like CreateUserServiceImpl, ReadUserServiceImpl,
UpdateUserServiceImpl, and DeleteUserServiceImpl. Isn't it an overkill to have lots of
classes?
Suppose I define 4 interfaces each for create, read, update, and delete operations and my service class implements all the four interfaces. Now I can only have a single implementation class but by separating their interfaces I have decoupled the concepts as far as rest of the application is concerned. Is this the right way or you see some problems in it?
686
The single responsibility principle (SRP) states that every class or module in a program should have responsibility for just a single piece of that program's functionality. Further, the elements of that responsibility should be encapsulated by the responsible class rather than spread out in unrelated classes.
A class should have only one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and if in the future we need to make one change we are going to make it in the class which handles it.
The Single Responsibility Principle (SRP) The idea behind the SRP is that every class, module, or function in a program should have one responsibility/purpose in a program. As a commonly used definition, "every class should have only one reason to change". The class above violates the single responsibility principle.
You are violating the single responsibility principle (SRP) as you are both representing data and performing logic in the same class." Like the others, I disagree with this. I would say that the SRP is violated if you are performing more than one piece of logic in the class.
That's what I love about patterns and principles - they are a consist way for everyone to disagree on software design as much as agree :-)
My view would be to build the class in whatever way makes it a usable and easy to understand class - depending on the complexity and context within which the class lives. With a simple implementation and context, a single class will do. You could say it does adhere to the SRP because it's responsibility is to manage the CRUD operations. But if the implementation is complex, or there's a lot of shared code that would be suitable for placing in an abstract parent class, then perhaps 4 separate classes, one for each CRUD operation make more sense. it's all about how you look at it.
Patterns and principles are great things, but used incorrectly they can make a simple problem just as complex as not having them.
122
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
