Single Responsibility Principle(SRP) and my Service Class

Question

I have YoutubeVideoService 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 CreateYoutubeVideoService, ReadYoutubeVideoService, UpdateYoutubeVideoService and DeleteYoutubeVideoService. Isn't it an overkill to have lots of classes?

Answer 1

I think you're taking the Single Reposibility Principle a bit to the extreme on a class level, without taking into consideration cohesion.

If you follow that route, you could justify having lots of classes with just one or two methods, which in turn would increase the number of dependencies to the sky.

I think the spirit of SRP is Simplify as much as you can, but not more.

Answer 2

A good way of measuring coherence to the Single Responsibility Principle is to think about how many reason to change this class has. If you can think more than one reason to change, probably it's violating the SRP.

The only reason to change a CRUD class like this, is a change in the underlaying data structure. So this respects the SRP.

On the other hand, if you had in that class any other operation (es. checking the video length or type before inserting it), that would violate SRP, since it could change independently from the persistency layer.

SRP is not a dogma, when following SOLID principles, we always have to be careful to not introduce needles complexity. As per Bob Martin's masterpiece, speaking about when two responsibility should be separated:

If, on the other hand, the application is not changing in ways that cause the two responsibilities to change at different times, there is no need to separate them. Indeed, separating them would smell of needless complexity. (…) is not wise to apply SRP (or any other principle, for that matter) if there is no symptom.

Answer 3

How long should a method be? One could say there is no reason to have more than 2 lines. But this is certainly overkill in some situations. Same with SRP - you have to decide when enough is enough. CRUD looks like a cohesive set of operations which are perfectly fit for single class, because they operate on same type of data.

Answer 4

Service classes are SRP killers. By definition they are an aggregation of operations - which is contrary to SRP. Often single method of the service would require some dependency, that all other methods might not care at all, then with each such method dependencies multiply, it leads to mess. Manager, Service, sometime Repository - these patterns are plain bad from dependencies point of view. In Commands/Queries/Requests world you would have these 3 commands and a query just grouped into a domain/directory. That leads to cleaner, smaller, easier to read and extendable code. Also to cleaner processes.