Refactoring 027 – How to Remove Getters | HackerNoon

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 😔

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 👣

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

Sample Code 💻

Before 🚨

public class Invoice {
    private List<LineItem> 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<LineItem> 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<LineItem> 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<LineItem> 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 📝

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

Level 🔋

See also 📚

Credits 🙏

Image by Kris on Pixabay

This article is part of the Refactoring Series.