For those not familiar with the single responsibility principle here is a good description from the
c2 wiki.
- Each responsibility should be a separate class, because each responsibility is an axis of change.
- A class should have one, and only one, reason to change.
- If a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.
It is a counter-intuitive but valuable principle of object-oriented design. I came across this example today:
My application is using a service layer between the UI and the domain model. On my ProductService I have a method that is used to add images to products. When an image is added it must be saved in three different sizes. The old me would have included the image resizing code in the ProductService, that is the intuitive thing to do.
Following the single responsibility principle I instead created an ImageResizingService class to handle the resizing. So now my ProductService is dependant upon ImageResizingService (or at least its interface) but it has no knowledge of how to resize an image, and my Image class remains gloriously dependency free.