title: Do polymorphism or conditionals promote better design?
body: <p>I recently stumbled across <a href="http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-decided-to.html" rel="noreferrer">this entry in the google testing blog</a> about guidelines for writing more testable code.  I was in agreement with the author until this point:</p>
  
  <blockquote>
    <p>Favor polymorphism over conditionals: If you see a switch statement you should think polymorphisms. If you see the same if condition repeated in many places in your class you should again think polymorphism. Polymorphism will break your complex class into several smaller simpler classes which clearly define which pieces of the code are related and execute together. This helps testing since simpler/smaller class is easier to test.</p>
  </blockquote>
  
  <p>I simply cannot wrap my head around that.  I can understand using polymorphism instead of RTTI (or DIY-RTTI, as the case may be), but that seems like such a broad statement that I can't imagine it actually being used effectively in production code.  It seems to me, rather, that it would be easier to add additional test cases for methods which have switch statements, rather than breaking down the code into dozens of separate classes.</p>
  
  <p>Also, I was under the impression that polymorphism can lead to all sorts of other subtle bugs and design issues, so I'm curious to know if the tradeoff here would be worth it.  Can someone explain to me exactly what is meant by this testing guideline?</p>