Feature envy anti-pattern

Feature envy is a cohesion smell: a method is defined on one class but spends most of its effort reading another object's data. The method may be correct, yet its location exposes callers to the other class's representation and makes the data owner less meaningful.

TL;DR

• Feature envy occurs when a method in class A spends most of its time accessing fields from class B, a sign the method belongs in B.
• It creates hidden coupling: when B's internal structure changes, the method in A breaks even though A "owns" it.
• The fix is Move Method: relocate the envious logic to the class that owns the data, then call it from A.
• Feature envy is the inverse of an anemic domain model. Both stem from separating behavior from data.
• Cross-cutting concerns (logging, formatting, metrics) that read from many objects are not feature envy.

The Problem

Your e-commerce codebase has an OrderService that calculates totals, discounts, and tax. Every computation reaches into Order to pull item prices, discount codes, and shipping addresses. The Order class itself is a plain data holder with zero behavior.

// OrderService calculates everything using Order's internals
public class OrderService {
    public BigDecimal calculateTotal(Order order) {
        BigDecimal subtotal = BigDecimal.ZERO;
        for (OrderItem item : order.getItems()) {
            subtotal = subtotal.add(
                item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())));
        }
        BigDecimal discount = order.getDiscountCode() != null
            ? subtotal.multiply(new BigDecimal("0.10"))
            : BigDecimal.ZERO;
        BigDecimal taxable = subtotal.subtract(discount);
        BigDecimal tax = taxable.multiply(new BigDecimal("0.08"));
        return taxable.add(tax);
    }

    public boolean isHighValue(Order order) {
        return calculateTotal(order).compareTo(new BigDecimal("500")) > 0;
    }

    public String getShippingSummary(Order order) {
        return order.getItems().size() + " items to "
            + order.getShippingAddress().getCity();
    }
}

Most methods in OrderService are about Order, not about OrderService. When the discount model changes from a flat 10% to tiered pricing, you update OrderService. When Order.items changes from a List to a Map, you update OrderService. The service is coupled to the entity's representation.

When another service needs the same calculation, it may copy the getter-heavy code rather than treating one location as canonical. The result is duplicated logic that can drift when the domain rule changes.

The service calls seven getters to do work that the entity should own. If any getter signature changes, the service breaks.

Why It Happens

1. Anemic domain model habit. Teams trained on "services do logic, entities hold data" write feature-envious code by default. The entity becomes a glorified struct.
2. IDE-generated getters. Auto-generating getters for every field invites other classes to reach in. Once getters exist, developers pull data out instead of pushing behavior in.
3. Fear of "fat" entities. Developers worry about putting logic in entities because "entities should be simple." But an Order that knows how to calculate its own total is cohesive when that behavior uses order data. The right question is which class has the information and the reason to change, not whether the method adds a line to the entity.
4. Gradual accretion. The first method is small. The second copies its pattern. By the tenth method, the service is a 400-line class that only touches foreign data.

How to Detect It