ExerciseDifficulty: Intermediate1 min

Practice: Naming the Symptom and the Principle

Five complaints from a team, each a symptom of design rot and a principle to reach for.

Diagnosing design rot from what a team says about its code is the skill practised here. For each complaint, name the symptom (rigidity, fragility, immobility or viscosity) and the SOLID principle you would reach for first. More than one principle can help; pick the one aimed most directly at the cause.

"We wanted to use the invoice formatting in the new mobile app, but it imports the whole billing database layer."
"Every time a new country is added, we edit the same tax calculation function and add another branch."
"Changing the font on the PDF report broke the monthly revenue figures."
"Our test needs a Printer fake, and the Printer interface has fourteen methods, so the fake has thirteen that do nothing."
"The ReadOnlyAccount subclass throws an error from withdraw, so the payments code now checks the account type before every call, and nobody wants to clean it up."

Show the answers

Each complaint, its symptom, the principle to reach for, and the clue that decides it
Complaint	Symptom	Principle	Clue
1, invoice formatting	Immobility	Dependency inversion	The useful part cannot move because it depends on a concrete database layer.
2, tax per country	Rigidity	Open/closed	Each new case means editing code that already works.
3, font and revenue	Fragility	Single responsibility	Formatting and calculation change for different reasons but live together.
4, fourteen-method printer	Rigidity	Interface segregation	The fake must depend on methods it never uses.
5, read-only account	Viscosity	Liskov substitution	The subclass breaks its parent's promise, and the type checks are the hack that piles up.

Complaint 5 shows two symptoms at once: the broken subclass is a Liskov failure, and the habit of adding type checks instead of fixing it is viscosity.

← → move through sections and cards