The SRP seens fairly reasonable when you first look at it. Every class should have one reason to change. Every class should take care of one thing. Right. But let's see this class:
This class was used as an example by Robert C. Martin. He describes three responsabilities for this class; calculating pay that deals with accounting, save and find by id that deals with database & describe employee that deals with formatting.
My issue is that if you take these responsabilities and separate them into classes, then Employee will become a data structure. It won't do anything. If in the future you need it do something, you can certainly call that just another responsability and decouple it too. This means that essentially, this is procedural programming. You can say 'compose Employee of those classes and put wrapper methods in the Employee for them', but then you end up with chains of wrapping. Maybe it's good practice but it feels wrong.
Another issue is what you consider a reason to change. It can be anything. If you say 'this class changes when the program changes' then everything goes into a class. If you say 'this class changes when the last digit of the last serial code printed in the 23th of May, after a virgin has been sacrificed to the moon goddess, changes' then there's a trillion classes. Should I just guide myself by a class cohesion? Should I forget completely about this "one reason to change" buzzword?