Question: Are there any design patterns/methods/ways to remove nested if then else conditions/switch statements?

I remember coming across some methods used by the Google folks listed in a Google code blog post. Can’t seem to find it now though

Answer: 
You want to use a refactoring that replaces a conditional using a polymorphic class. For [example](http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html). 

Or here's another [example](http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism)

Essentially the ideal is very simple you create an object heirarchy, and move the various behaviors into an overriden method. You will still need a method to create the right class but this can be done using a factory pattern.

Edit
====

Let me add that this is not a perfect solution in every case. As (I forgot your name sorry) pointed in my comments, some times this can be a pain especially if you have to create an object model just to do this. This refactoring excells if you have this:

```
function doWork(object x)
{

   if (x is a type of Apple)
   {
      x.Eat();

   } else if (x is a type of Orange)
   {
      x.Peel();
      x.Eat();
   }

}

```

Here you can refactor the switch into some new method that each fruit will handle.

Edit
====

As someone pointed out how do you create the right type to go into doWork, there are more ways to solve this problem then I could probally list so some basic ways. The first and most straight forward (and yes goes against the grain of this question) is a switch:

```
class FruitFactory
{
   Fruit GetMeMoreFruit(typeOfFruit)
   {
         switch (typeOfFruit)
         ...
         ...
   }
}

```

The nice thing about this approach is it's easy to write, and is usually the first method I use. While you still have a switch statement its isolated to one area of code and is very basic all it returns is a n object. If you only have a couple of objects and they;re not changing this works very well. 

Other more compelx patterns you can look into is an [Abstract Factory](http://en.wikipedia.org/wiki/Abstract_factory_pattern). You could also dynamically create the Fruit if your platform supports it. You could also use something like the [Provider Pattern](http://en.wikipedia.org/wiki/Provider_pattern). Which essentially to me means you configure your object and then you have a factory which based on the configuration and a key you give the factory creates the right class dynamically.
I actually wrote about how to solve this issues in my blog in April of 2008. Take a look [here](http://adotnetdude.blogspot.com/2008/03/refactoring-code-with-too-many.html) and let me know what you think.

I recommend you: 

1. Use polymorphism to get the correct run-time behavior you need without conditional statements.
2. Take all your conditional statements, and move them into some sort of "factory" which will hand you the appropriate type at run-time.
3. You're done. Wasn't that easy? :)

If you want to see some actual code sample on how transform your code, head over to my blog.

*P.S. This is not a cheap attempt at self promotion; I've been a SO user for a long time now, and this is the first time I've linked to my blog - and I've only done so because I think it's relevant.*