I might have read this somewhere before, but I can't remember exactly where (if nowhere).
In any event, my own experience corroborates this phantom memory, which is that a major code smell is the existence of classes that are purely data holders - the equivalent of C structs. An example of such a smell is a Java Bean with only fields and getter and setter methods. That's not an object - it's a ghetto type-safe associative array (a map from field names to values, like a JSON object).
Whenever you spot these objects, turn your nose away in disgust. After the nausea passes, go look for the duplication. Refactor it away. Code duplication is almost always a symptom of this code stench. If it's an object, it should do something, and its state should be encapsulated. If its state is encapsulated (meaning you can't see or directly access it), what's left but behavior? But if your pseudo-object has only un-encapsulated state (that is, fields, getters, and setters that you directly manipulate), then it has the exact opposite features that it should have. It's an anti-object, and a stinky one at that.
0 comments:
Post a Comment