Q: Nested switches or multiple functions, what would be a better design? I have a large method that looks something like this
List<Hotel> findAvailHotels(Provider provider, Method method, List<String> codes) {
    switch (provider) {
        case PROVIDER_1:
            //TODO Do common things to provider 1
            switch (method) {
                case HOTEL_CODE:
                    break;
                case DESTINATION_CODE:
                    break;
                case GEO:
                    break;
            }
            break;
        case PROVIDER_2:
            switch (method) {
                case HOTEL_CODE:
                    break;
                case DESTINATION_CODE:
                    break;
                case GEO:
                    break;
            }
            break;
    }

So each time I need to add a provider I'll need to add a case to that provider and then repeat the method switch for this new provider.
I got a suggestion from a fellow that should be split into methods for each method so for example instead of the above, it'll be
List<Hotel> findAvailHotelsByHotelCode(Provider provider, List<String> codes) {
    switch (provider) {
        case PROVIDER_1:
            //TODO Do common things to provider 1
            break;
        case PROVIDER_2:
            break;
    }

List<Hotel> findAvailHotelsByDestinationCode(Provider provider, List<String> codes) {
    switch (provider) {
        case PROVIDER_1:
            //TODO Do common things to provider 1
            break;
        case PROVIDER_2:
            break;
    }

List<Hotel> findAvailHotelsByGeo(Provider provider, List<String> codes) {
    switch (provider) {
        case PROVIDER_1:
            //TODO Do common things to provider 1
            break;
        case PROVIDER_2:
            break;
    }


Personal thoughts: Maybe splitting into multiple methods makes it more cleaner but if I need to do common stuff to PROVIDER_1 (despite the method) then this common thing will need to be repeated/duplicated in each method (as indicated by the //TODOs in the above code) which kinda means more lines of code but that's a bit irrelevant maybe.
I'd like to hear some thoughts about this, which would you consider more readable and more clean? Any better alternatives?

edit: To give more context, I work with hotel providers.. most providers have 3 common methods of search (hotel_code, destination_code, geo).. from outside this method I can do a hotel_code search for all providers (by looping over the Provider enum and calling the method for each provider with hotel_code enum param).. or I can do it to a specific provider.

A: Your Question is still a little too abstract to suggest a "best" solution, but Timothy is right so far - in either case you can use polimorphism.
I suggest Strategy pattern because you define the broad structure by using an interface and create an a dedicated class for every single algorithm (provider in your case).
This has at least two advantages:  


*

*You have an easy to oversee List of algorithms in the form of classes.

*You can replace the outer switch by a loop through your strategy objects.


Hmm - since you asked for it - here is some example code (a little large though ...) 
import java.util.ArrayList;
import java.util.List;

public class HotelStuff {

  private static class Hotel{/* does whatever ...*/}

  private enum SearchMethod{
    HOTELCODE,
    DESTINATIONCODE,
    GEOCODE
  }

  private interface Providable{
    List<Hotel> findAvailHotels(SearchMethod method, List<String> codes); 
  }

  private static class Provider1 implements Providable{
    @Override
    public List<Hotel> findAvailHotels(SearchMethod method, List<String> codes) {
        // TODO create the list ...
        return null;
    }
  }

  public static void main(String[] args) {
    // TODO Auto-generated method stub
    List<Providable> providers = new ArrayList<Providable>();
    providers.add(new Provider1());
    // providers.add(new Provider2 .. and so on     
    List<String> codes = Arrays.asList("123","456");
    SearchMethod method = SearchMethod.GEOCODE;
    List<Hotel> availableHotels = findAvailHotels(providers, method, codes);
  }

  public static List<Hotel> findAvailHotels(List<Providable> providers, SearchMethod method, List<String> codes) {
    List<Hotel> result = new ArrayList<Hotel>();
    List<Hotel> partResult;
    for(Providable provider: providers) {
        partResult = provider.findAvailHotels(method, codes);
        result.addAll(partResult);
    }
    return result;
  }

}

Of course you should implement the classes in seperate files - i just put them into one file to shorten it.

A: Unless your switch statement is in a factory you should better use polymorphism.

A: You should look into both the visitor pattern and double dispatch.
The Gang of Four defines the Visitor as:

Represent an operation to be performed on elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

In your case Provider is the object and Method is the operation.
Double dispatch is useful in situations where the choice of computation depends on the runtime types of its arguments. In your case: you want to do something based on the type of Provider and Method.
