title: How to apply Single Responsibility Principle to a service class
body: <p>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 <code>CreateUserServiceImpl</code>, <code>ReadUserServiceImpl</code>, 
  <code>UpdateUserServiceImpl</code>, and <code>DeleteUserServiceImpl</code>. Isn't it an overkill to have lots of 
  classes?</p>
  
  <p>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?</p>