Separate non-communicating behaviour
m |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Aidan Bebbington) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 6: | Line 6: | ||
If such non-communicating behavior is found, it should be separated into two separate classes. | If such non-communicating behavior is found, it should be separated into two separate classes. | ||
| + | |||
| + | However, it is not necessary for the two sets of behavior to be completely non-communicating. If they communicate very little, and that communication can be easily captured by a public interface, then there may also be cause for separating these two sets of behavior. | ||
==See also== | ==See also== | ||
Latest revision as of 03:18, 25 November 2010
- Spin off non-related information into another class (i.e., non-communicating behavior). --Riel's Heuristic 2.10, Arthur Riel 1996
This heuristic tells developers to look for classes where some of the methods operate on one set of data members and the rest of the methods operate on different data members. This non-communicating behavior indicates that two classes that should be separated have been combined into one.
In the extreme case, half of the methods in a class may operate on half of the data members and the other half of the methods may operate on the other half of the data members. In this case, the two sets of data and behavior are clearly not related since there is no communication between them.
If such non-communicating behavior is found, it should be separated into two separate classes.
However, it is not necessary for the two sets of behavior to be completely non-communicating. If they communicate very little, and that communication can be easily captured by a public interface, then there may also be cause for separating these two sets of behavior.
