Message chain smell
m (category) |
m (→See Also) |
||
| Line 16: | Line 16: | ||
* [[Tell, don't ask]] | * [[Tell, don't ask]] | ||
* [[Refactoring]] | * [[Refactoring]] | ||
| + | |||
| + | {{Template:CodeSmells}} | ||
[[Category:Code smells]] | [[Category:Code smells]] | ||
Latest revision as of 09:31, 14 October 2009
The message chain smell arises when a particular class is highly coupled to other classes in chain-like delegations. To illustrate this smell, suppose we have Class A who needs data from Class E. To retrieve this data, object A firstly needs to retrieve object E from object D from object C from object B. Thus we have something like this:
a.getB().getC().getD().getE().getTheData();
The problem which lies here is that as A tried to access the data at Class E, A becomes unnecessarily coupled to class B, C, D along the way; when it needs only to get the data from E.
However, sometimes delegations are needed, and thus delegation chains with a couple of links are often considered to be harmless. The argument as to how many links a chain can reasonably have is often related to other factors. Consider the other design maxims mentioned below for more guidance related to designs with highly coupled chained delegations.
Refactoring Techniques
- Hide Delegate in conjunction with Extract Method or Move methods - to minimise some of the chaining.
- Consider Law of Demeter or Tell, don't ask design maxims.
See Also
