Feature envy smell
From CSSEMediaWiki
(Difference between revisions)
m (→See Also) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Jenny Harlow) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | The feature envy smell is present when a class or a method or methods from that class use methods from another class excessively, in particular if a method seems more 'interested' in another class than its own. This is a good sign that some [[Refactoring|refactoring]] should be applied. | + | The feature envy smell is present when a class or a method or methods from that class use methods from another class excessively, in particular if a method seems more 'interested' in another class than its own. The most common focus of the envy is the data. This is a good sign that some [[Refactoring|refactoring]] should be applied. |
Discretion still needs to be applied since particular library methods may get used a lot, but this doesn't necessarily mean we should try to refactor around this. | Discretion still needs to be applied since particular library methods may get used a lot, but this doesn't necessarily mean we should try to refactor around this. | ||
Line 8: | Line 8: | ||
*[[Extract Method]] - if only a part of a method is envious | *[[Extract Method]] - if only a part of a method is envious | ||
*[[Extract Class]] - if several methods are envious and they don't belong in the envied class either | *[[Extract Class]] - if several methods are envious and they don't belong in the envied class either | ||
+ | |||
+ | ==Opposing forces== | ||
+ | Martin Fowler ([[Martin Fowler 1999|Refactoring : improving the design of existing code]] noted that there are some patterns that break this rule:<blockquote>"Both [[Strategy Pattern]] and [[Visitor|Visitor Pattern]] do this. These are used to combat the [[Divergent change smell]]. "The fundamental rule of thumb is to put things together that change together. Data and behaviour that references that data usually change together but there are exceptions. When the exceptions occur, we move the behavior to keep changes in one place. Strategy and Visitor allow you to change behavior easily, because they isolate the small amount of behavior that needs to be overridden, at the cost of further indirection." [[Martin Fowler 1999]]</blockquote> | ||
== See Also == | == See Also == | ||
Line 13: | Line 16: | ||
*[[Code smells]] | *[[Code smells]] | ||
*[[Coupling and cohesion]] | *[[Coupling and cohesion]] | ||
+ | *[[Keep related data and behavior in one place]] | ||
{{Template:CodeSmells}} | {{Template:CodeSmells}} | ||
[[Category:Code smells]] | [[Category:Code smells]] |
Latest revision as of 03:17, 25 November 2010
The feature envy smell is present when a class or a method or methods from that class use methods from another class excessively, in particular if a method seems more 'interested' in another class than its own. The most common focus of the envy is the data. This is a good sign that some refactoring should be applied.
Discretion still needs to be applied since particular library methods may get used a lot, but this doesn't necessarily mean we should try to refactor around this.
Refactoring Methods
- Move Method - if a particular method is using methods from another class excessively, move it to that class
- Extract Method - if only a part of a method is envious
- Extract Class - if several methods are envious and they don't belong in the envied class either
Opposing forces
Martin Fowler (Refactoring : improving the design of existing code noted that there are some patterns that break this rule:"Both Strategy Pattern and Visitor Pattern do this. These are used to combat the Divergent change smell. "The fundamental rule of thumb is to put things together that change together. Data and behaviour that references that data usually change together but there are exceptions. When the exceptions occur, we move the behavior to keep changes in one place. Strategy and Visitor allow you to change behavior easily, because they isolate the small amount of behavior that needs to be overridden, at the cost of further indirection." Martin Fowler 1999
See Also