This question on SO talks about correcting what the OP thought is feature envy code. Another example where I saw this nifty phrase being quoted is in a recently given answer here in programmers.SE. Although I did drop in a comment to that answer asking for the information I thought it would of general help to programmers following Q&A to understand what is meant by the term feature-envy. Please feel free to edit additional tags if you think appropriate.
-
possible duplicate of How large is ok for a Class? See also: Is it a code smell if an object knows a lot of its owner?– gnatSep 22, 2013 at 8:56
Add a comment
|
2 Answers
Feature envy is a term used to describe a situation in which one object gets at the fields of another object in order to perform some sort of computation or make a decision, rather than asking the object to do the computation itself.
As a trivial example, consider a class representing a rectangle. The user of the rectangle may need to know its area. The programmer could expose width and height fields and then do the computation outside of the Rectangle class. Alternatively, Rectangle could keep the width and height fields private and provide a getArea method. This is arguably a better approach.
The problem with the first situation, and the reason it is considered a code smell, is because it breaks encapsulation.
As a rule of thumb, whenever you find yourself making extensive use of fields from another class to perform any sort of logic or computation, consider moving that logic to a method on the class itself.
-
11+1, though your example is not realistic, since a useful Rectangle class would typically expose width and height fields either. Sep 21, 2013 at 6:57
-
5And though the breaking of encapsulation may a occur together with "Feature envirism", in most real-world examples I have seen so far it was probably not the case. It happens more in situations "hey, I need to compute some things just in the code using that object, and I am not sure if I can touch that object's implementation / if we should give the object the responsibility for that computation". And then one implements the calculation using fields which are already exposed (though a much cleaner implementation would be probably possible within the object). Sep 21, 2013 at 7:09
-
2@DocBrown Imagine a rectangle drawn on the surface of a torus, cone or sphere. If my shape-drawing library produces objects which are capable of producing the correct results in such contexts, you'd be foolish not to leave them to calculate their own areas - in any context.– itsbruceSep 21, 2013 at 9:24
-
1@OskarN.: By definition we're talking about functions that are needed. They're obviously needed if other classes are re-implementing them over and over again. Sep 24, 2013 at 0:11
-
2@OskarN.: it depends; sometimes the decision is clear, sometimes its a matter of taste, and most often its a matter of experience. In your article, there are good reasons why Scott Meyers writes "sometimes less is more", and that it took him years to understand when not to apply his "algorithm for deciding when to make f a member function". Sep 24, 2013 at 5:40
There is a possible situation when it is OK to use another class/struct methods extensively - when your class/struct is a container for data. Usually there is a little you can do with this data without external context.
Such classes can still hold some internal logic but more often they are used as containers:
class YourUid {
public:
YourUid(int id_in_workplace_, int id_in_living_place_, DB* FBI_database, int id_in_FBI_database);
bool IsInvalidWorker() const { return id_in_workplace == consts::invalid_id_in_workplace; }
bool CanMessWith() const { return !FBI_database_.is_cool(id_in_FBI_database_); }
int id_in_workplace;
int id_in_living_place;
private:
int id_in_FBI_database_;
const DB* FBI_database_;
};
@jhewlett in his answer refers to this article to prove that you should no use other class members extensively, but there is another code smells situation described there with advocates my example:
Long Parameter List. Limit the number of parameters you need in a given method, or use an object to combine the parameters.
-
2
-
@gnat The Q is about Why it is considered "code smell". jhewlett gives an A with some too general assumtions questioned in the comments. My answer is 2 cents to distinguish "code smell" from normal practice.– RigaSep 23, 2013 at 22:42