Divergent Change
One class is changed in different ways for different reasons.
“When one class is commonly changed in different ways for different reasons.” – Fowler & Beck
Violates SRP.
Signs of Use (Symptoms)
- You change the same class for “Database changes” AND for “UI changes”.
- Different teams constantly conflict in the same file.
Why it is bad (Consequences)
- Merge Conflicts: Everyone works on the same file.
- Impact Analysis: One change might break unrelated features.
Why it happens (Root Cause)
A class grew organically to handle multiple responsibilities.
When it might be okay (Exceptions)
- Rarely. A Facade might have multiple reasons, but it should delegate.
Explanation
Problem
OrderController handles HTTP parsing, validation, business logic, and database access. Change in any of those areas means editing this one file.
The Flaw
SRP violation. Class has too many reasons to change.
Real world analogy
A single government office that handles passports, taxes, AND marriage licenses. Any policy change (tax law, immigration, family law) requires updating the same office.
Refactoring Solution
- Extract Class: Split the class based on responsibility.
Pros and Cons (of the Antipattern)
| Pros (Why people do it) | Cons (The price you pay) |
|---|---|
Comparison
- Related Antipatterns: Large Class.
- Related Principles: Violates SRP.
Code example
Typescript
Bad (The Antipattern)
Good (The Fix)