Eliminate case analysis
(New page: It is usually a mistake to explicitly check what class an object belongs to before performing some action on it. Instead, a message should be passed to the object in question, and each pos...) |
|||
| Line 2: | Line 2: | ||
This rule also applies to case analysis of the value of variables. It is usually better to have a separate class for each kind of variable, instead of one class that can represent several types of variable and differentiate between them based on the value of an instance variable. | This rule also applies to case analysis of the value of variables. It is usually better to have a separate class for each kind of variable, instead of one class that can represent several types of variable and differentiate between them based on the value of an instance variable. | ||
| + | |||
| + | Riel's heuristics [[Beware type switches]] and [[Beware value switches]] are derived from this idea. | ||
== See Also == | == See Also == | ||
Revision as of 03:48, 6 October 2008
It is usually a mistake to explicitly check what class an object belongs to before performing some action on it. Instead, a message should be passed to the object in question, and each possible object should define the method that is being called and respond in their own way. In other words, each method in the possible objects that were being checked contains one of the cases.
This rule also applies to case analysis of the value of variables. It is usually better to have a separate class for each kind of variable, instead of one class that can represent several types of variable and differentiate between them based on the value of an instance variable.
Riel's heuristics Beware type switches and Beware value switches are derived from this idea.
