Eliminate case analysis
m (Reverted edits by Ebybymic (Talk); changed back to last version by Stephen Fitchett) |
|||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
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. | 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. | ||
Latest revision as of 03:08, 25 November 2010
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.
