The Utils Package That Holds Everything
The third sign of a Single Responsibility Principle violation: a commons or utils package that quietly becomes a dumping ground, with java.util as the most famous example.
The previous post covered two signs of an SRP violation: too many if-else branches, and a monster method doing more than its name promises. There's a third sign.
Sign 3: The "Utils" Package That Holds Everything
It hides in a place almost every codebase has: a package called commons, utils, or helpers.
Think honestly about how something ends up in there. A class needs a home. Nobody's sure where it belongs. So it goes into utils, because that's where things with no clear home end up.
A package is a code unit too, the same as a class or a method. SRP applies to it exactly the same way: it should have one responsibility, one reason to change. So ask the same question of a utils package that you'd ask of any class: what is this package's single responsibility?
There isn't one. Its real responsibility is "hold whatever didn't fit anywhere else." That's not a responsibility. That's the absence of one.
That's why utils packages grow forever. Nobody can predict what's in them without opening the file.
This isn't a small-company problem either. Modern code editors at companies like Google flag it automatically: try to create a package named commons, and the IDE warns you on the spot that it's a bad practice and suggests removing it.
Even Java's Standard Library Has One
The best-known example of this mistake is java.util, part of Java's own standard library. Open it up: Map, List, Deque, sure. But also Calendar, Formatter, Optional, Random, Scanner.
java.util isn't "data structures." It's everything that didn't have an obvious home, filed under one generic name.
It still exists because too much code across the world already depends on it exactly as-is. Renaming or splitting it now would break that code. That's not proof the design was good. It's proof that bad structure survives once enough code depends on it.
A better version would have split it by what it actually holds:
java.util/
├── collectionUtils/ Map, List, Deque, ...
├── calendarUtils/ Calendar, ...
├── inputUtils/ Scanner, ...
└── formatUtils/ Formatter, ...Same "utils" name, but now each package has exactly one real responsibility instead of all of them. A package's name should reveal what it's responsible for, the same rule that applies to a class.
This Isn't Just Theory
SRP shows up in real industrial refactoring work too, not just interview questions.
- An industrial study across two large systems, 1,500+ classes combined, tracks what actually happens when teams refactor toward single-responsibility classes at that scale.
- A legacy-codebase experience report from ASML, spanning 5,000+ source files, treats SRP, and the rest of SOLID, as repeatable refactoring patterns, not abstract advice.
Bird, from the earlier posts, now has its SRP problem fully diagnosed. The next post picks up the actual fix, and finds a second SOLID rule breaking inside the exact same class.
Keep reading