The OP asks "but why should a class have one single Reason To Change™?"
Answer is in the text - "If a class has more than one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed."
The case the OP makes for mixing Business logic and Persistance is really ironic too. In thinking he's arguing \against\ SRP, the poor example he gives actually argues \for\ it. Yes, validation and persistance usually conceptually go together as one responsibility - storing your data. Calculating payroll (see PDF), is a whole different responsibility, better suited for a separate abstraction. So the strawman argument is not really in the PDF.
The book mentions the "Unbalanced" counterpoint already. See: "If, on the other hand, the application is not changing in ways that cause the the two responsibilities to change at differen times, then there is no need to separate them. Indeed, separating them would smell of Needless Complexity.
There is a corrolary here. An axis of change is only an axis of change if the changes actually occurr. It is not wise to apply the SRP, or any other principle for that matter, if there is no symptom."
Now for the amazing TLDR of the entire piece, it goes something like this: SRP is not a clear and fundamentally objective design principle, so let me offer another principle huff huff but dont worry its not clear cut (so dont follow it?!)!
This doesn't lead anywhere. Talking to the co-worker more might have been better than adopting a defensive attitude.
The big lesson here is, learn concepts like Cohesion vs Coupling, SRP, design patterns, to give you a common vocabulary, but keep your mind open and try to write code that is well organized and is free of code smells. If anybody has suggestions on how things can be improved, measure their suggestion on its merits. Software development is an excercise in balancing all kinds of different types of concerns - pun intended :). Sit down and list pros and cons between alternative approaches, and let the design that best addresses the problem/constraints at hand win.
And even better, next time, if you want to save yourself some trouble, ask others for their opinions and share your concerns with the code before you even write a line of code. Then nobody will get 'religious' in a code review and it will allow a team to focus on results.
The OP asks "but why should a class have one single Reason To Change™?" Answer is in the text - "If a class has more than one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed."
The case the OP makes for mixing Business logic and Persistance is really ironic too. In thinking he's arguing \against\ SRP, the poor example he gives actually argues \for\ it. Yes, validation and persistance usually conceptually go together as one responsibility - storing your data. Calculating payroll (see PDF), is a whole different responsibility, better suited for a separate abstraction. So the strawman argument is not really in the PDF.
The book mentions the "Unbalanced" counterpoint already. See: "If, on the other hand, the application is not changing in ways that cause the the two responsibilities to change at differen times, then there is no need to separate them. Indeed, separating them would smell of Needless Complexity. There is a corrolary here. An axis of change is only an axis of change if the changes actually occurr. It is not wise to apply the SRP, or any other principle for that matter, if there is no symptom."
Now for the amazing TLDR of the entire piece, it goes something like this: SRP is not a clear and fundamentally objective design principle, so let me offer another principle huff huff but dont worry its not clear cut (so dont follow it?!)!
This doesn't lead anywhere. Talking to the co-worker more might have been better than adopting a defensive attitude.
The big lesson here is, learn concepts like Cohesion vs Coupling, SRP, design patterns, to give you a common vocabulary, but keep your mind open and try to write code that is well organized and is free of code smells. If anybody has suggestions on how things can be improved, measure their suggestion on its merits. Software development is an excercise in balancing all kinds of different types of concerns - pun intended :). Sit down and list pros and cons between alternative approaches, and let the design that best addresses the problem/constraints at hand win.
And even better, next time, if you want to save yourself some trouble, ask others for their opinions and share your concerns with the code before you even write a line of code. Then nobody will get 'religious' in a code review and it will allow a team to focus on results.