How granular do I get with my class design when trying to follow the SOLID principles?

Question

I have an interface for Client Registration called IRegistrationService. This contains one method called Register and it is implemented through the class RegistrationService. If I wanted to have methods for Delete, Update, Retrieve for example, would I create a separate interface for each action such as IDeletionService, IUpdateService, IRetrieveService or just put all the methods into IRegistrationService. The reason I ask this is because this is what the SOLID principles especially the SRP principle seem to ask.

Answer 1

One way of stating the Single Responsibility Principle is that a class should have only one reason to change. That doesn't necessarily mean that it only does one thing, but rather that it only deals with one sphere of responsibility.

So it's fine for your registration service to know all about people getting registered, and I'd include removing, updating, retrieving registrations in that. If the registration process changes (e.g. you decide that all new or updated users get sent an email) than the class changes. However, the implementation details of how the registration email gets sent do not belong in this service -- that would be a second reason the class might change (e.g. you realize you want to send emails via an external SMTP server rather than locally, or via SMS rather than email, etc.).