Beware value switches

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
Switching of values is bad, boys and girls, because it's not transparent. A typical bad example is:
+
:''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:
  
  
Line 10: Line 12:
 
   switch (bird_type) {
 
   switch (bird_type) {
 
     case EAGLE:
 
     case EAGLE:
     // blah
+
     doEagleBehaviour();
 
     case DOVE:
 
     case DOVE:
     // blah
+
     doDoveBehaviour();
 
     case PIGEON:
 
     case PIGEON:
     // blah
+
     doPigeonBehaviour();
 
   }
 
   }
 
   }
 
   }
Line 30: Line 32:
 
* 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).
 
* 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]]
+
Riel derived this idea from [[Johnson and Foote 1988]]: [[Eliminate case analysis]]
  
 
== See also ==
 
== See also ==
 
* [[Eliminate case analysis]]
 
* [[Eliminate case analysis]]
 
* [[Riel's heuristics]]
 
* [[Riel's heuristics]]
 +
 +
[[Category:Riel's heuristics]]

Revision as of 00:11, 21 July 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