Beware value switches

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
(New page: Switching of values is bad, boys and girls, because it's not transparent. A typical bad example is: class Bird { int bird_type; const int EAGLE = 1; const int DOVE = 2; const in...)
 
m (Reverted edits by Ebybymic (Talk); changed back to last version by Stephen Fitchett)
 
(4 intermediate revisions by 3 users not shown)
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 29: Line 31:
 
* If you can't, keep the switch statement as hidden as possible, keep it as small as possible, and:  
 
* 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).
 
* 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 ==
 +
* [[Beware type switches]]
 +
* [[Eliminate case analysis]]
 +
* [[Riel's heuristics]]
 +
 +
[[Category:Riel's heuristics]]

Latest revision as of 03:08, 25 November 2010

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