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 ⚙️ Refactoring 027 - Remove Getters Maxi Contieri Maxi Contieri Maxi Contieri Follow Apr 18 '25 Refactoring 027 - Remove Getters #webdev #programming #beginners #java 3 reactions Add Comment 17 min read Refactoring 013 - Remove Repeated Code Maxi Contieri Maxi Contieri Maxi Contieri Follow Jun 16 '24 Refactoring 013 - Remove Repeated Code #webdev #beginners #programming #tutorial 2 reactions Add Comment 3 min read 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 based on the same value.
They also call the getter and write their own version of the comparison.
Now two places decide what that value means, and neither of them is the object that owns it.
Typical.
You didn't add a second getter this time.
You reused the first one, because it was already there.
That's the trap.
The getter existed for one reason, and you let it justify skipping the real fix: a method on the object that answers the question itself, instead of handing out the raw value for every caller to interpret on their own.
Sample Code 💻 Wrong 🚫 Right 👉 Detection 🔍 [X] Manual This is a design smell, and no linter is coming to save you.
Search for a getter that appears inside , comparison, or filter expressions in more than one place outside its own class.
If two call sites read the same getter and each writes its own comparison against it, the object is missing a method, and the getter is carrying logic it was never meant to carry.
Exceptions 🛑 The smell appears when you reuse that same getter as a shortcut for business logic instead of adding the method the logic actually belongs to.
Don't point to DTOs as a counterexample.
A DTO doesn't excuse this.
It just breaks encapsulation on purpose and gives the practice a name.
Tags 🏷️ Encapsulation Level 🔋 [x] Intermediate Why the Bijection Is Important 🗺️ The rule behind that value is a concept that belongs to the object in the MAPPER, not to whichever function happens to call the getter first.
When you keep that rule inside the object, every caller shares the same bijection between the object and the real-world thing it represents.
When you let each caller reimplement the rule from a getter, you create as many private definitions of that concept as you have call sites, and they drift apart the moment one of them changes.
AI Generation 🤖 AI generators create this smell often.
You ask for a function that needs a value the object already exposes through a getter, and it writes a standalone function around that getter, because that's the smallest diff that satisfies the request.
It won't add a method to the object unless you ask for that explicitly.
AI Detection 🧲 AI can detect it, but only if you point it at the pattern.
Try: "Find getters called from more than one place where the caller performs its own comparison or business rule on the result." Without that prompt, the code passes tests and looks idiomatic, so most assistants won't flag it on their own.
Try Them! 🛠 Remember: AI Assistants make lots of mistakes Suggested Prompt: Move the comparison logic from external functions into a real method on the object so callers stop reimplementing it from the getter Without Proper Instructions With Specific Instructions ChatGPT ChatGPT Claude Claude Perplexity Perplexity Copilot Copilot You You Gemini Gemini DeepSeek DeepSeek Meta AI Meta AI Grok Grok Qwen Qwen Conclusion 🏁 A getter you added for one legitimate reason doesn't grant permission to skip every method that comes after it.
When you find yourself reaching for an existing getter to write new business logic outside the object, stop and add the method instead.
The object already knows the information.
Let it hold the rule too.
Stop treating it like a vending machine that only hands out data to whoever asks nicely.
Relations 👩❤️💋👨 Code Smell 68 - Getters Maxi Contieri Maxi Contieri Maxi Contieri Follow Apr 29 '21 Code Smell 68 - Getters #codenewbie #tutorial #oop #programming 3 reactions 2 comments 2 min read Code Smell 89 - Math Feature Envy Maxi Contieri Maxi Contieri Maxi Contieri Follow Oct 4 '21 Code Smell 89 - Math Feature Envy #oop #webdev #cleancode #tutorial 6 reactions 4 comments 2 min read Code Smell 63 - Feature Envy Maxi Contieri Maxi Contieri Maxi Contieri Follow Mar 23 '21 Code Smell 63 - Feature Envy #codenewbie #programming #oop #webdev 6 reactions 2 comments 2 min read Code Smell 01 - Anemic Models Maxi Contieri Maxi Contieri Maxi Contieri Follow Oct 20 '20 Code Smell 01 - Anemic Models #codenewbie #oop #beginners #computerscience 63 reactions 12 comments 2 min read Code Smell 246 - Expiration Date Maxi Contieri Maxi Contieri Maxi Contieri Follow Apr 9 '24 Code Smell 246 - Expiration Date #webdev #java #beginners #tutorial 4 reactions 6 comments 3 min read Code Smell 64 - Inappropriate Intimacy Maxi Contieri Maxi Contieri Maxi Contieri Follow Mar 27 '21 Code Smell 64 - Inappropriate Intimacy #codenewbie #codesmell #webdev #oop 7 reactions Add Comment 1 min read More Information 📕 Nude Models — Part II : Getters Maxi Contieri Maxi Contieri Maxi Contieri Follow Feb 23 '21 Nude Models — Part II : Getters #webdev #programming #oop #tutorial 7 reactions 1 comment 7 min read Tell, Don't Ask Encapsulation Quote OOP to me means only messaging, local retention and protection and hiding of state-process.
Alan Kay Disclaimer 📘 Code Smells are my opinion.
Credits 🙏 Photo by Nathália Rosa on Unsplash This article is part of the CodeSmell Series.
How to Find the Stinky parts of your Code Maxi Contieri Maxi Contieri Maxi Contieri Follow May 21 '21 How to Find the Stinky parts of your Code #codenewbie #tutorial #codequality #beginners 23 reactions Add Comment 14 min read