Code Smell 321 - Getter Piggybacking
One broken window invites another
TL;DR: Don't reuse an existing getter to bolt on new business logic from outside the object.
Problems 😔
- Duplicated business rules
- Broken encapsulation
- Scattered comparison logic
- Hidden domain knowledge
- Fragile refactoring
- Law of Demeter violation
Solutions 😃
- Add real behavior methods
- Keep comparisons inside object
- Pass collaborators, not primitives
- Reserve getters for rendering
- Follow tell, don't ask
Refactorings ⚙️
Context 💬
An object exposes a getter for one legitimate reason: some other part of the system needs to read that value, usually to display it.
Getters are a code smell, but this one gets a pass, for now.
Later on, you discover that you need new business logic that depends on the same value.
You already have the getter, so you write a function outside the object that calls it and does the comparison itself, breaking the encapsulation principle.
Someone else needs slightly different logic...
Copyright of this story solely belongs to hackernoon.com. To see the full text click HERE
