title: How to refactor nested switch statements best?
body: <p>ok so here is my problem.</p>
  
  <p>basically a have a structure like this (regular table):</p>
  
  <pre><code>   | a1 | a2 | a3 | a4 
  ----------------------
  b1 | v1 | v2 | v3 | v4
  ----------------------
  b2 | v5 | v6 | v7 | v8
  ----------------------
  b3 | v9 | vA | vB | vC
  </code></pre>
  
  <p>atm. the a-values are inside an enum (enumA), also the b-values (enumB)
  a1 - a4 can be selected via a combobox that is bound to the enum, same for b1 - b3.</p>
  
  <p>based on the selection of both I have specific values that are assigned to an aXbY combination and returned for further calculation.
  these values are selected via a nested switch statement like this:</p>
  
  <pre><code>switch (enumA) {
     case a1:
         switch (enumB) {
             case b1: return v1;
             case b2: return v2;
  </code></pre>
  
  <p>and so on.</p>
  
  <p>What I want to know is how to refactor my code best to improve code quality.
  edit: I am looking for an object oriented solution!</p>
  
  <p>Note: I don't expect a or b to grow at all. Yet, lets asume that I am in a situation where I do. Lets also asume that I expect enumA to grow more likely then enumB.</p>
  
  <p>What I though about so far:</p>
  
  <p><strong>Strategy Pattern hardcore all the way</strong></p>
  
  <p>I could refactor every "ab" combination to its own type, that implements a common interface and every type returns the correct value.</p>
  
  <p>pros: </p>
  
  <ul>
  <li>no nested blown up switch statement.</li>
  <li>open closed principle yay.</li>
  </ul>
  
  <p>cons: </p>
  
  <ul>
  <li>seems like an overkill to have a type for every combination.</li>
  <li>I would lose the structure because I could theoretically have an a1b4 combination without the equivalent a2b4 and so on.</li>
  </ul>
  
  <p><strong>Strategy Pattern for enumA, Exact Method for enumB</strong></p>
  
  <p>I could refactor a1-aN to types, that all implement the same interface, which has the three methods getB1, getB2, getB3 that return the appropriate value.</p>
  
  <p>pros: </p>
  
  <ul>
  <li>I can throw away the outer switch.</li>
  <li>I can enforce the table structure with the common interface.</li>
  </ul>
  
  <p>cons:</p>
  
  <ul>
  <li>violation of open closed principle since I have to change the interface once a new b values comes in and also adjust every type with that interface.</li>
  <li>I still have the inner switch statement in order to evalueate which method to pick.</li>
  </ul>
  
  <p>Are there better patterns for my situation? Is there a way to stay flexible while still enforcing the table structure? If I use types, instead of enums, how to make the transition to the UI? Use reflection to get every class that implements a certain interface and show the name (or whatever property) in the combobox?</p>