Beware value switches

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m
Line 35: Line 35:
  
 
== See also ==
 
== See also ==
 +
* [[Beware type switches]]
 
* [[Eliminate case analysis]]
 
* [[Eliminate case analysis]]
 
* [[Riel's heuristics]]
 
* [[Riel's heuristics]]
  
 
[[Category:Riel's heuristics]]
 
[[Category:Riel's heuristics]]

Revision as of 10:31, 11 October 2009

Explicit case analysis on the value of an attribute is often an error. The class should be decomposed into an inheritance hierarchy where each value of the attribute is transformed into a derived class. --Riel's Heuristic 5.13, Arthur Riel 1996

Switching of values lacks transparency. A typical bad example is:


class Bird {
 int bird_type;
 const int EAGLE = 1;
 const int DOVE = 2;
 const int PIGEON = 3;
 move() {
  switch (bird_type) {
   case EAGLE:
    doEagleBehaviour();
   case DOVE:
    doDoveBehaviour();
   case PIGEON:
    doPigeonBehaviour();
  }
 }
}


Here, this code is screaming out for subclasses, and one can usually make the code much cleaner by using subclasses.

As usual though, there are exceptions. Factory methods generally require a switch statement of some sort.

The key things to remember are:

  • Replace switch statements with subclasses if you can.
  • If you can't, keep the switch statement as hidden as possible, keep it as small as possible, and:
  • Strongly avoid switching on the same thing in multiple places in the code. Ignore this and the likely result is a maintainability nightmare (every time you change the switch, you've got to change several bits of code).

Riel derived this idea from Johnson and Foote 1988: Eliminate case analysis

See also

Personal tools