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 ⚙️ 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 🚫 // Food needs to show its use-by date on the shelf // label, so useByDate(