''This page is about the CodeSmell. For another meaning, see FeatureEnvy.''

"The whole point of objects is that they are a technique to package data with the processes used on that data. A classic [code] smell is a method that seems more interested in a class other than the one it is in. The most common focus of the envy is the data."  

	* Fowler, RefactoringImprovingTheDesignOfExistingCode, Chap. 3, p. 80.

[''An inherited object seems awful envious of the class it is inheriting from. Also, the object seems awful envious of the libraries of the operating system that the object is wrapping. I don't think we should use phrases like '''interested''', since code and machines do not have human qualities such as '''interest''' or '''envy'''. Rephrased, one could claim that a method which references or calls too many other methods and data existing in other classes is a CodeSmell. However, I'm not so sure this is true - as some classes heavily wrap (i.e are envious of) operating system libraries (which could be considered classes).''] Code doesn't have a smell either...

[''If the class wraps or inherits the properties, then they properly belong to the inheriting object.  Envy comes in when the object is accessing properties that do not properly belong to it.'']

Local example in ManifestResponsibility.

Another example in DataEnvy.

Refactor using
	* MoveMethod when the whole method clearly wants to be elsewhere, or
	* ExtractMethod when only part the method is envious...or even
	* ExtractClass if there are several envious methods and the functionality doesn't quite belong in the other object either.

CategoryCodeSmell