Single responsibility vs encapsulation
c#, encapsulation, single-responsibility-principle, solid-principles
Solution
In the scenario you have described, you don't need to break your `Customer` class into multiple Add/Update/Delete Customer classes - in fact that would almost certainly make your system more difficult to understand.
Incidentally, and I could be wrong, it sounds like you are using something like the Active Record pattern; there is nothing wrong with this pattern per-se, but it is a violation of SRP and it's not the most testable of patterns so I would be inclined to recommend you take an alternative approach.
Single Responsibility Principle
SRP states that a class should have one, and only one, reason to change. But if you think about what you currently have, your `Customer` class already has two responsibilities and therefore already has two possible reasons to change
- Representing the data and behaviour of a Customer in whatever application domain you are implementing
- Persisting its own data (i.e all the CRUD operations).
So if the underlying database changes, you need to update the Customer class methods that deal with persistence, and if the required behaviour of Customer changes, you have to update the Customer class to implement the new behaviour.
How it helps
When you have a situation like this, there's always a chance that your `Customer` class will end up with mixed code that entwines both business logic and database persistence logic into a highly-coupled mess such that later on you find it very difficult to make changes to one aspect without causing problems in the other. I have been there and it's not fun, so do bear this in mind; that's really what the SRP is all about - avoiding the classic "Big Ball of Mud" situation.
Where to go from here
- If you really want to follow the "S" in SOLID* then I'd recommend starting with something like the Repository pattern to handle the actual persistence of the `Customer` class to and from your database (the `Repository` class you create will of course itself adhere to the SRP because it is only concerned with CRUD to the database and doesn't contain any "business logic" related to `Customer`
- Once you are comfortable with this approach, you can if you like then move on to something like the Command pattern, a good example is here and you can read about the Query pattern here (you'll need both). But there is nothing wrong with a nice, simple Repository pattern either.
*It's probably not something that can be absolutely proven, but I've personally found that code which sticks to SOLID principles tends to be very testable, very easy to understand and change, and very robust. Then again, that's just me so YMMV!
Problem
I am trying to understand a little bit more about single responsibility. If I try and represent a customer that could be added, removed, updated, retrieved then In the past my customer class would have all add,remove,update and get methods on it. This helped in encapsulating the behavior of a real world the customer in one class. With single responsibility do I end up breaking my customer class into AddCustomer class, delete customer class, update customer class and Get customer class and maybe even a get all customer class?