The principle in practice:

What "one reason to change" means: A "reason to change" maps to a stakeholder or a business concern. Authentication changes when security requirements evolve. Profile management changes when product requirements evolve. Different drivers = different classes.

Signs of SRP violation:

• Class names that include "And," "Manager," "Processor," or "Handler" — these words signal the class is too broad to name precisely.
• Classes with many instance variables, especially when some methods use some variables and other methods use others — this is two classes wearing a trench coat.
• Classes where you cannot describe the purpose in one sentence without using "and."
• When a bug fix in one method unexpectedly breaks a different method in the same class.

The common objection: "But then I'll have too many small classes!" Martin's answer: a system with many small, focused classes is easier to understand than one with a few massive, tangled ones. You don't reduce complexity by having fewer classes — you reduce it by having clearer boundaries. A toolbox with organized compartments is easier to navigate than a single drawer of loose tools, even though the toolbox has "more containers."

SRP and cohesion: A class is cohesive when every method uses every instance variable. Maximum cohesion = SRP naturally satisfied. When cohesion drops, it's a signal that the class should be split.