I am continuing my reading of Agile Software Development - Principles, Patterns, and Practices by Robert C. Martin (Amazon). Chapter 8 talks about the Single-Responsibility Principle:
As the chapter explains, the single-responsibility principle is more frequently known as cohesion (High Cohesion GRASP Pattern), which is the functional relatedness of the elements of a module. Basically, you want to keep classes, functions, etc. focused so that there is only one reason for them to change. This is the reason why many people separate their applications into layers, for example. The data access layer provides persistence and re-hydration of business objects. The business layer is all about business rules. And, the presentation layer is only about presenting information to the user. Hopefully a change in one layer won't cause a ripple effect of changes in other layers, or at least, keep the impact to a minimum.
Robert provides a couple of examples in the brief 3 page chapter. A popular example that "violates" this principle is placing persistence logic in your business classes. By doing so, you have 2 reasons for a business class to change. First, when you need to change the persistence logic, and second, when you need to change the business rules. Fowler describes this type of domain model as Active Record (details), and although it violates this principle, Active Record is successfully used in many applications. These principles are only guidelines and you have to weigh the pros and cons of following these guidelines as all of them impact time of delivery, cost, and maintainability.
However, the author reinforces that we should be thinking about "real" changes - focusing on things that most likely could change. If you don't see your data access logic changing, then Active Record may not be violating this principle at all. So many people build their applications so that they can switch databases, swich persistence logic, etc., but in reality this may not happen. So, when we look at these axis of change for a particular class, function, layer, etc., the author stresses to only focus on those pieces that really could change.
A good example of sticking to this principle could be found in an off-the-shelf, e-commerce application. When calculating shipping costs on a particular sale, the developers of the e-commerce application don't want the Sale class calculating shipping costs. Each online store has their own rules for calculating shipping costs on a sale, and the developers would want shipping costs calculated by a separate class that contains the business rules for each store. By placing shipping calculations in a separate class, the Sale class does not have to change everytime the shipping calculations change. As a result, shipping calculations are usually placed in separate, pluggable classes that implement the Strategy Pattern.
So far, the book is excellent and you might be interesting in reading about other chapters:
As I mentioned before, you can read about this principle here on the author's website.