How to apply Single Responsibility Principle to a service class

Question

Hello

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?

Thanks

Shekhar

Answer 1

It does not violate the single responsibility principle till the service is responsible for the data services of a single type or business info.

Answer 2

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.