Feature Envy

When a method relies on multiple properties or methods from another class.

Sign of Smell

When a method is envious and contains behavior that rightly belongs to another class, it is considered a smell called Feature Envy. This smell indicates that the feature could be defined in a better location. The most common focus of envy in this smell is the data. Another similar code smell is Data Envy, which focuses on the data of another object but is not widely accepted as an independent smell.

"Feature Envy" refers to a method that excessively depends on another class. If a class excessively depends on another class, please refer to "Inappropriate Intimacy".

Reason of Smell

  • High Coupling: Feature envy increases coupling between classes, making code harder to maintain and modify. Excessive dependence in one method on another class may require corresponding changes, leading to a fragile codebase.

  • Low Cohesion: ****Feature envy is often a symptom of low cohesion. It occurs when a method in a class accesses another class to perform actions that are related to a different responsibility, instead of encapsulating those actions within itself.

  • Violation of Encapsulation: Feature envy occurs when one method frequently accesses the internals of another class, violating encapsulation. This can result in data inconsistencies and bugs.

  • Anemic Domain Models: ****Feature envy often indicates the presence of anemic domain models. This is because it implies that behavior related to a specific feature is spread out across multiple classes, instead of being encapsulated within the domain model where it logically belongs.

  • Tell, Don't Ask: ****The principle of "Tell, Don't Ask" suggests instructing objects to perform actions instead of constantly querying data and making decisions based on it. Feature envy often occurs when an object repeatedly requests data from another class.

  • Law of Demeter: The Law of Demeter, also called the "principle of least knowledge," states that a class should have limited knowledge of another class's internal structure. Feature envy happens when a method excessively relies on and knows about another class's internals, instead of interacting through well-defined interfaces.

Refactoring Recipes

  • Extract Method

  • Move Method

  • Move Field

Extract Method

First, identify any code in the method that excessively accesses properties or methods of another class. Then, extract this code into a new method within the class that owns the data or behavior.

This new method should encapsulate the logic related to the desired feature, making it easier to manage and understand.

Move Method

To address Feature Envy, move the method that is envious of another class's features to the class that actually owns those features. This reorganizes the code and assigns responsibilities more appropriately.

Move Field

The "Move Field" refactoring skill involves transferring a field (property or variable) from one class to another when it is more closely related to the latter class.

To address Feature Envy, consider relocating a field that another class frequently accesses to the class where it logically belongs. This will ensure that the data is encapsulated and managed by the appropriate class.

Reference

https://wiki.c2.com/?FeatureEnvySmell

https://code-smells.com/couplers/feature-envy

https://refactoring.guru/smells/feature-envy

https://github.com/troessner/reek/blob/master/docs/Feature-Envy.md

https://devlead.io/DevTips/FeatureEnvy

Last updated