Feature Envy

Refactoring & Technical Debt

Meaning

Feature Envy is a code smell where a method accesses the data of another object more than its own data, indicating poor encapsulation. It violates the principle of keeping related data and behavior together, leading to fragile code that breaks when the envied class changes. Developers reach for this concept during refactoring to identify methods that should be moved to the class they envy.

Primary Function

Code Quality

Communicative Purpose

Identifies methods that are overly dependent on another class's data to guide refactoring toward better encapsulation.

Pattern

Recognize when a method in class A uses more attributes/methods of class B than its own.

Core Structure

Recognize method uses other class's data

Função primária

Code Quality

Propósito comunicativo

Identifies methods that are overly dependent on another class's data to guide refactoring toward better encapsulation.

Situações de gatilho

Object-oriented programming: a method in Class A frequently calls getters on Class B; Refactoring: preparing to move a method to the class it uses most; Code review: spotting tight coupling between classes via excessive attribute access.

Contextos

Object-oriented design, refactoring practices, software maintenance, Java/C#/Python codebases

Padrão

Recognize when a method in class A uses more attributes/methods of class B than its own.

Estrutura central

Recognize method uses other class's data

Colocados típicos

Extract Method
Move Method
Getter/Setter encapsulation

Substituições comuns

Data Clumps (when multiple attributes are always used together) → indicates need for a new class
Primitive Obsession (using primitives instead of objects) → may mask envy

Erros comuns

Confusing Feature Envy with legitimate collaboration → causes unnecessary refactoring that breaks valid interactions Only looking at direct attribute access → misses envy via temporary variables or method chains Failing to consider behavioral envy → overlooks when a method calls another object's behaviors excessively

Similar / contraste

Data Clumps: related data that always appears together (vs. Feature Envy: one class using another's data); Intimacy: two classes excessively coupled (vs. Feature Envy: directional envy from one class to another)

Interferências

Coming from procedural programming: may not see encapsulation as important → remember OOP bundles data with functions that operate on it

Família do chunk

Data Clumps
Primitive Obsession
Switch Statements

Nuance

Do not use when the method genuinely belongs to the envied class (e.g., factory methods); Performance impact is negligible as it's a design smell; Boundary case: envy is acceptable if the class is a pure data transfer object (DTO) with no behavior

Efeito pragmático

Prevents shotgun changes and improves maintainability by ensuring each class has a single responsibility for its data

Dica de memória

Feature Envy: like a coworker who constantly borrows your tools instead of using their own toolbox

Nota

Feature Envy often appears together with other smells such as Data Clumps, God Class, and Intimacy, and addressing it can simplify refactoring by revealing misplaced responsibilities.

Upgrade path

Move Method refactoring

Frequência: HighFormulaicidade: FixedTipo de construção: conceptPrioridade de aquisição: Recognition firstPrioridade de output: InputTag de espaçamento: Medium-term

Examples

class Order: def calculate_total(self): return sum(item.price * item.quantity for item in self.items) class Item: def __init__(self, price, quantity): self.price = price self.quantity = quantity # The method above does NOT show Feature Envy because it uses its own `items` attribute.

class Order: def calculate_total(self): total = 0 for item in self.items: total += item.get_price() * item.get_quantity() # Envy: accessing Item's internals return total class Item: def __init__(self, price, quantity): self._price = price self._quantity = quantity def get_price(self): return self._price def get_quantity(self): return self._quantity

class Order: def calculate_total(self): return self._calculate_items_total() # Fixed: moved logic to Order def _calculate_items_total(self): return sum(item.price * item.quantity for item in self.items) class Item: def __init__(self, price, quantity): self.price = price self.quantity = quantity