Refactoring 027 - How to Remove Getters

Unleash object behavior beyond data access TL;DR: Remove or replace getters with behavior-rich methods that perform operations instead of exposing internal state. Problems Addressed 😔 Anemic objects Excessive coupling Lost encapsulation Essence Mutation Law of Demeter violations Information leakage Exposed internals Primitive Obsession Related Code Smells 💨 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxix https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv Steps 👣 Identify getters that expose internal object state Find all getter usages in the codebase Move behavior that uses the getter into the object itself Create intention-revealing methods that perform operations (remove the get prefix) Update your code to use the new methods Sample Code 💻 Before 🚨 public class Invoice { private List items; private Customer customer; private LocalDate dueDate; public Invoice(Customer customer, LocalDate dueDate) { this.customer = customer; this.dueDate = dueDate; this.items = new ArrayList<>(); } public void addItem(LineItem item) { // This is the right way // to manipulate the internal consistency // adding assertions and access control if necessary items.add(item); } public List getItems() { // You are exposing your internal implementation // In some languages, you also open a backdoor to // manipulate your own collection unless you return // a copy return items; } public Customer getCustomer() { // You expose your accidental implementation return customer; } public LocalDate getDueDate() { // You expose your accidental implementation return dueDate; } } Invoice invoice = new Invoice(customer, dueDate); // Calculate the total violating encapsulation principle double total = 0; for (LineItem item : invoice.getItems()) { total += item.getPrice() * item.getQuantity(); } // Check if the invoice is overdue boolean isOverdue = LocalDate.now().isAfter(invoice.getDueDate()); // Print the customer information System.out.println("Customer: " + invoice.getCustomer().getName()); After 👉 public class Invoice { private List items; private Customer customer; private LocalDate dueDate; public Invoice(Customer customer, LocalDate dueDate) { this.customer = customer; this.dueDate = dueDate; this.items = new ArrayList<>(); } public void addItem(LineItem item) { items.add(item); } // Step 3: Move behavior that uses the getter into the object public double calculateTotal() { // Step 4: Create intention-revealing methods double total = 0; for (LineItem item : items) { total += item.price() * item.quantity(); } return total; } public boolean isOverdue(date) { // Step 4: Create intention-revealing methods // Notice you inject the time control source // Removing the getter and breaking the coupling return date.isAfter(dueDate); } public String customerInformation() { // Step 4: Create intention-revealing methods // You no longer print with side effects // And coupling to a global console return "Customer: " + customer.name(); } // For collections, return an unmodifiable view if needed // Only expose internal collaborators if the name // is an actual behavior public List items() { return Collections.unmodifiableList(items); } // Only if required by frameworks // or telling the customer is an actual responsibility // The caller should not assume the Invoice is actually // holding it public String customerName() { return customer.name(); } // You might not need to return the dueDate // Challenge yourself if you essentially need to expose it // public LocalDate dueDate() { // return dueDate; // } } // Client code (Step 5: Update client code) Invoice invoice = new Invoice(customer, dueDate); double total = invoice.calculateTotal(); boolean isOverdue = invoice.isOverdue(date); System.out.println(invoice.customerInformation()); Type 📝 [x]Semi-Automatic Safety 🛡️ This refactoring is generally safe but requires careful execution. You need to ensure all usages of the getter are identified and replaced with the new behavior methods. The biggest risk occurs when getters return mutable objects or collections, as client code might have modified these objects. You should verify that behavior hasn't changed through comprehensive tests before and after refactoring. For collections, return unmodifiable copies or views to maintain safety during transition. For frameworks requiring property access, you may need to preserve simple accessors without the "get" prefix alongside your behavior-rich methods. As usual, you should add behavioral coverage (not structural) to your code before you perform the refactoring. Why is the Code Better? ✨ The refactored code is better because it adheres to the Tell-Don't-Ask principle, making your objects intelligent rather than just anemic data holders. The solution centralizes logic related to the object's data within the object itself, reducing duplication. It hides implementation details, allowing you to change internal representation without affecting client code This approach reduces coupling as clients don't need to know about the object's internal structure. It also prevents violations of the Law of Demeter by eliminating chains of getters. Since the essence is not mutated, the solution enables better validation and business rule enforcement within the object. How Does it Improve the Bijection? 🗺️ Removing getters improves the bijection between code and reality by making objects behave more like their real-world counterparts. In the real world, objects don't expose their internal state for others to manipulate - they perform operations based on requests. For example, you don't ask a bank account for its balance and then calculate if a withdrawal is possible yourself. Instead, you ask the account, "Can I withdraw $100?" The account applies its internal rules and gives you an answer. You create a more faithful representation of domain concepts by modeling your objects to perform operations rather than exposing the data. This strengthens the one-to-one correspondence between the real world and your computable model, making your code more intuitive and aligned with how people think about the problem domain. This approach follows the MAPPER principle by ensuring that computational objects mirror real-world entities in structure and behavior. Limitations ⚠️ Frameworks and libraries often expect getter methods for serialization/deserialization. Legacy codebases may have widespread getter usage that's difficult to refactor all at once. Unit testing may become more challenging as the internal state is less accessible. Remember, you should never test private methods. Refactor With AI 🤖 Suggested Prompt: 1. Identify getters that expose internal object state 2. Find all getter usages in the codebase 3. Move behavior that uses the getter into the object itself 4. Create intention-revealing methods that perform operations (remove the get prefix) 5. Update your code to use the new methods Without Proper Instructions With Specific Instructions ChatGPT ChatGPT Claude Claude Perplexity Perplexity Copilot Copilot Gemini Gemini DeepSeek DeepSeek Meta AI Meta AI Grok Grok Qwen Qwen Tags 🏷️ Encapsulation Level 🔋 [x]Intermediate Related Refactorings 🔄 https://hackernoon.com/refactoring-remove-setters-codesmell?embedable=true https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true https://maximilianocontieri.com/refactoring-009-protect-public-attributes?embedable=true https://hackernoon.com/refactoring-016-building-with-the-essence?embedable=true See also 📚 https://hackernoon.com/nude-models-part-ii-getters-sjo3ua2?embedable=true https://en.wikipedia.org/wiki/Law_of_Demeter?embedable=true https://martinfowler.com/bliki/TellDontAsk.html?embedable=true Credits 🙏 Image by Kris on Pixabay This article is part of the Refactoring Series. https://maximilianocontieri.com/how-to-improve-your-code-with-easy-refactorings?embedable=true Unleash object behavior beyond data access Unleash object behavior beyond data access TL;DR: Remove or replace getters with behavior-rich methods that perform operations instead of exposing internal state. TL;DR: Remove or replace getters with behavior-rich methods that perform operations instead of exposing internal state. Problems Addressed 😔 Anemic objects Excessive coupling Lost encapsulation Essence Mutation Law of Demeter violations Information leakage Exposed internals Primitive Obsession Anemic objects Anemic Excessive coupling coupling Lost encapsulation Essence Mutation Essence Mutation Law of Demeter violations Information leakage Exposed internals Primitive Obsession Primitive Obsession Related Code Smells 💨 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxix https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxix https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv Steps 👣 Identify getters that expose internal object state Find all getter usages in the codebase Move behavior that uses the getter into the object itself Create intention-revealing methods that perform operations (remove the get prefix) Update your code to use the new methods Identify getters that expose internal object state Find all getter usages in the codebase Move behavior that uses the getter into the object itself Create intention-revealing methods that perform operations (remove the get prefix) Update your code to use the new methods Sample Code 💻 Before 🚨 public class Invoice { private List items; private Customer customer; private LocalDate dueDate; public Invoice(Customer customer, LocalDate dueDate) { this.customer = customer; this.dueDate = dueDate; this.items = new ArrayList<>(); } public void addItem(LineItem item) { // This is the right way // to manipulate the internal consistency // adding assertions and access control if necessary items.add(item); } public List getItems() { // You are exposing your internal implementation // In some languages, you also open a backdoor to // manipulate your own collection unless you return // a copy return items; } public Customer getCustomer() { // You expose your accidental implementation return customer; } public LocalDate getDueDate() { // You expose your accidental implementation return dueDate; } } Invoice invoice = new Invoice(customer, dueDate); // Calculate the total violating encapsulation principle double total = 0; for (LineItem item : invoice.getItems()) { total += item.getPrice() * item.getQuantity(); } // Check if the invoice is overdue boolean isOverdue = LocalDate.now().isAfter(invoice.getDueDate()); // Print the customer information System.out.println("Customer: " + invoice.getCustomer().getName()); public class Invoice { private List items; private Customer customer; private LocalDate dueDate; public Invoice(Customer customer, LocalDate dueDate) { this.customer = customer; this.dueDate = dueDate; this.items = new ArrayList<>(); } public void addItem(LineItem item) { // This is the right way // to manipulate the internal consistency // adding assertions and access control if necessary items.add(item); } public List getItems() { // You are exposing your internal implementation // In some languages, you also open a backdoor to // manipulate your own collection unless you return // a copy return items; } public Customer getCustomer() { // You expose your accidental implementation return customer; } public LocalDate getDueDate() { // You expose your accidental implementation return dueDate; } } Invoice invoice = new Invoice(customer, dueDate); // Calculate the total violating encapsulation principle double total = 0; for (LineItem item : invoice.getItems()) { total += item.getPrice() * item.getQuantity(); } // Check if the invoice is overdue boolean isOverdue = LocalDate.now().isAfter(invoice.getDueDate()); // Print the customer information System.out.println("Customer: " + invoice.getCustomer().getName()); After 👉 public class Invoice { private List items; private Customer customer; private LocalDate dueDate; public Invoice(Customer customer, LocalDate dueDate) { this.customer = customer; this.dueDate = dueDate; this.items = new ArrayList<>(); } public void addItem(LineItem item) { items.add(item); } // Step 3: Move behavior that uses the getter into the object public double calculateTotal() { // Step 4: Create intention-revealing methods double total = 0; for (LineItem item : items) { total += item.price() * item.quantity(); } return total; } public boolean isOverdue(date) { // Step 4: Create intention-revealing methods // Notice you inject the time control source // Removing the getter and breaking the coupling return date.isAfter(dueDate); } public String customerInformation() { // Step 4: Create intention-revealing methods // You no longer print with side effects // And coupling to a global console return "Customer: " + customer.name(); } // For collections, return an unmodifiable view if needed // Only expose internal collaborators if the name // is an actual behavior public List items() { return Collections.unmodifiableList(items); } // Only if required by frameworks // or telling the customer is an actual responsibility // The caller should not assume the Invoice is actually // holding it public String customerName() { return customer.name(); } // You might not need to return the dueDate // Challenge yourself if you essentially need to expose it // public LocalDate dueDate() { // return dueDate; // } } // Client code (Step 5: Update client code) Invoice invoice = new Invoice(customer, dueDate); double total = invoice.calculateTotal(); boolean isOverdue = invoice.isOverdue(date); System.out.println(invoice.customerInformation()); public class Invoice { private List items; private Customer customer; private LocalDate dueDate; public Invoice(Customer customer, LocalDate dueDate) { this.customer = customer; this.dueDate = dueDate; this.items = new ArrayList<>(); } public void addItem(LineItem item) { items.add(item); } // Step 3: Move behavior that uses the getter into the object public double calculateTotal() { // Step 4: Create intention-revealing methods double total = 0; for (LineItem item : items) { total += item.price() * item.quantity(); } return total; } public boolean isOverdue(date) { // Step 4: Create intention-revealing methods // Notice you inject the time control source // Removing the getter and breaking the coupling return date.isAfter(dueDate); } public String customerInformation() { // Step 4: Create intention-revealing methods // You no longer print with side effects // And coupling to a global console return "Customer: " + customer.name(); } // For collections, return an unmodifiable view if needed // Only expose internal collaborators if the name // is an actual behavior public List items() { return Collections.unmodifiableList(items); } // Only if required by frameworks // or telling the customer is an actual responsibility // The caller should not assume the Invoice is actually // holding it public String customerName() { return customer.name(); } // You might not need to return the dueDate // Challenge yourself if you essentially need to expose it // public LocalDate dueDate() { // return dueDate; // } } // Client code (Step 5: Update client code) Invoice invoice = new Invoice(customer, dueDate); double total = invoice.calculateTotal(); boolean isOverdue = invoice.isOverdue(date); System.out.println(invoice.customerInformation()); Type 📝 [x]Semi-Automatic [x] Semi-Automatic [x] Safety 🛡️ This refactoring is generally safe but requires careful execution. You need to ensure all usages of the getter are identified and replaced with the new behavior methods. The biggest risk occurs when getters return mutable objects or collections, as client code might have modified these objects. You should verify that behavior hasn't changed through comprehensive tests before and after refactoring. For collections, return unmodifiable copies or views to maintain safety during transition. For frameworks requiring property access, you may need to preserve simple accessors without the "get" prefix alongside your behavior-rich methods. As usual, you should add behavioral coverage (not structural) to your code before you perform the refactoring. Why is the Code Better? ✨ The refactored code is better because it adheres to the Tell-Don't-Ask principle, making your objects intelligent rather than just anemic data holders. Tell-Don't-Ask The solution centralizes logic related to the object's data within the object itself, reducing duplication. It hides implementation details, allowing you to change internal representation without affecting client code This approach reduces coupling as clients don't need to know about the object's internal structure. coupling It also prevents violations of the Law of Demeter by eliminating chains of getters. Since the essence is not mutated , the solution enables better validation and business rule enforcement within the object. essence is not mutated How Does it Improve the Bijection? 🗺️ Removing getters improves the bijection between code and reality by making objects behave more like their real-world counterparts. bijection In the real world, objects don't expose their internal state for others to manipulate - they perform operations based on requests. For example, you don't ask a bank account for its balance and then calculate if a withdrawal is possible yourself. Instead, you ask the account, "Can I withdraw $100?" The account applies its internal rules and gives you an answer. You create a more faithful representation of domain concepts by modeling your objects to perform operations rather than exposing the data. This strengthens the one-to-one correspondence between the real world and your computable model, making your code more intuitive and aligned with how people think about the problem domain. This approach follows the MAPPER principle by ensuring that computational objects mirror real-world entities in structure and behavior. MAPPER Limitations ⚠️ Frameworks and libraries often expect getter methods for serialization/deserialization. Legacy codebases may have widespread getter usage that's difficult to refactor all at once. Unit testing may become more challenging as the internal state is less accessible. Remember, you should never test private methods. Refactor With AI 🤖 Suggested Prompt: 1. Identify getters that expose internal object state 2. Find all getter usages in the codebase 3. Move behavior that uses the getter into the object itself 4. Create intention-revealing methods that perform operations (remove the get prefix) 5. Update your code to use the new methods Suggested Prompt: 1. Identify getters that expose internal object state 2. Find all getter usages in the codebase 3. Move behavior that uses the getter into the object itself 4. Create intention-revealing methods that perform operations (remove the get prefix) 5. Update your code to use the new methods Without Proper Instructions With Specific Instructions ChatGPT ChatGPT Claude Claude Perplexity Perplexity Copilot Copilot Gemini Gemini DeepSeek DeepSeek Meta AI Meta AI Grok Grok Qwen Qwen Without Proper Instructions With Specific Instructions ChatGPT ChatGPT Claude Claude Perplexity Perplexity Copilot Copilot Gemini Gemini DeepSeek DeepSeek Meta AI Meta AI Grok Grok Qwen Qwen Without Proper Instructions With Specific Instructions Without Proper Instructions Without Proper Instructions With Specific Instructions With Specific Instructions ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT Claude Claude Claude Claude Claude Claude Claude Claude Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Copilot Copilot Copilot Copilot Copilot Copilot Copilot Copilot Gemini Gemini Gemini Gemini Gemini Gemini Gemini Gemini DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek Meta AI Meta AI Meta AI Meta AI Meta AI Meta AI Meta AI Meta AI Grok Grok Grok Grok Grok Grok Grok Grok Qwen Qwen Qwen Qwen Qwen Qwen Qwen Qwen Tags 🏷️ Encapsulation Encapsulation Level 🔋 [x]Intermediate [x] Intermediate [x] Related Refactorings 🔄 https://hackernoon.com/refactoring-remove-setters-codesmell?embedable=true https://hackernoon.com/refactoring-remove-setters-codesmell?embedable=true https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true https://hackernoon.com/improving-the-code-one-line-at-a-time?embedable=true https://maximilianocontieri.com/refactoring-009-protect-public-attributes?embedable=true https://maximilianocontieri.com/refactoring-009-protect-public-attributes?embedable=true https://hackernoon.com/refactoring-016-building-with-the-essence?embedable=true https://hackernoon.com/refactoring-016-building-with-the-essence?embedable=true See also 📚 https://hackernoon.com/nude-models-part-ii-getters-sjo3ua2?embedable=true https://hackernoon.com/nude-models-part-ii-getters-sjo3ua2?embedable=true https://en.wikipedia.org/wiki/Law_of_Demeter?embedable=true https://en.wikipedia.org/wiki/Law_of_Demeter?embedable=true https://martinfowler.com/bliki/TellDontAsk.html?embedable=true https://martinfowler.com/bliki/TellDontAsk.html?embedable=true Credits 🙏 Image by Kris on Pixabay Kris Pixabay This article is part of the Refactoring Series. https://maximilianocontieri.com/how-to-improve-your-code-with-easy-refactorings?embedable=true https://maximilianocontieri.com/how-to-improve-your-code-with-easy-refactorings?embedable=true