Single responsibility vs encapsulation

Question

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?

Answer 1

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!

Answer 2

No it does not have to be like that because SRP means that there should be only a single reason for your class to change. You question is very generic though, so my answer is of similar quality. I could not help wondering for instance why a customer should be able to add himself, ... SRP is a matter on how you phrase what a class responsibility is, and about layering, it should not be bothered about the details on how exactly to achieve those responsibilities. It must stay at its own abstraction layer.

See also http://en.wikipedia.org/wiki/Single_responsibility_principle

But note that the reason for change is very important , more than the fact that it should be responsible for a single thing only. Multiple actions might belong together and hence you would still have a single reason to change.

You might want to take a look at the whole SOLID acronym.