Multiple If-else ou enum - lequel est préférable et pourquoi?

Vous avez déjà de bonnes réponses sur l'amélioration de votre utilisation des Énumérations. Quant à savoir pourquoi ils sont mieux que les constantes de chaîne:

Je pense que le plus grand avantage est au moment de la compilation de vérification d'erreur. Si je devais faire appel growAFruit("watermelon")le compilateur n'a aucune idée de chose qui n'allait pas. Et depuis que je l'ai orthographié correctement, il ne va pas se démarquer comme une erreur lorsque vous affichez le code. Mais si je devais WATERMELEN.growAFruit()le compilateur peut vous dire tout de suite que j'ai mal orthographié.

Vous obtenez également de définir growAFruit comme un tas de simple, facile à lire, méthodes, au lieu d'un gros bloc de if-then-elses. Cela devient encore plus évident lorsque vous avez quelques dizaines de fruits, ou lorsque vous commencez à ajouter harvestAFruit()packageAFruit()sellAFruit()etc. Sans les énumérations, vous seriez copie de votre grand if-else bloc de tous les cours, et si vous avez oublié d'ajouter un cas, il tombe à travers les cas de défaut ou de ne rien faire, alors qu'avec les énumérations, le compilateur peut vous dire que la méthode n'a pas été mis en œuvre.

Encore plus au compilateur de vérifier la bonté: Si vous aussi vous avez un growVegetable méthode et les constantes de chaîne, il n'y a rien qui vous empêche d'appeler growVegetable("pineapple") ou growFruit("peas"). Si vous avez un "tomato" constante, la seule façon de savoir si vous considérez que c'est un fruit ou un légume est de lire le code source de la pertinence des méthodes. Une fois de plus, avec les énumérations, le compilateur peut vous le dire tout de suite si vous avez fait quelque chose de mal.

Un autre avantage est qu'il groupes de constantes liées ensemble, et leur donne une bonne maison. L'autre solution étant un tas de public static final champs jeté dans quelque classe que ce qui arrive à les utiliser, ou collé une interface de constantes. L'interface complète des constantes n'a même pas de sens parce que si vous n'avez pas besoin de définir l'enum est beaucoup plus facile que l'écriture de l'interface. Aussi, dans des classes ou des interfaces, il ya la possibilité d'utiliser accidentellement la même valeur pour plus d'une constante.

Ils sont également itérable. Pour obtenir toutes les valeurs de l'enum, vous pouvez simplement appeler Fruit.values()alors qu'avec des constantes que vous devez créer et de remplir votre propre tableau. Ou si simplement à l'aide de littéraux comme dans votre exemple, il n'y a aucune autorité liste des valeurs valides.

Le Tour de Bonus: IDE Soutien

• Avec un enum, vous pouvez utiliser votre IDE de l'auto-complétion et automatisé refactorings
• Vous pouvez utiliser des choses comme "Trouver des Références" dans Eclipse avec les valeurs de l'enum, alors que vous auriez à faire un texte brut de recherche pour trouver les littéraux de chaîne, qui sera généralement aussi de retour beaucoup de faux-positifs (événement si vous utilisez static final constantes, quelqu'un pourrait avoir utilisé le littéral de chaîne, quelque part)

La raison principale pas d'utiliser un enum serait si vous ne connaissez pas toutes les valeurs possibles au moment de la compilation (c'est à dire vous avez besoin d'ajouter plus de valeur à ce que le programme est en cours d'exécution). Dans ce cas, vous souhaiterez peut-être définir comme une classe de la hiérarchie. Aussi, ne pas jeter un tas de sans rapport avec les constantes dans un enum et l'appeler un jour. Il devrait y avoir une sorte de fil conducteur qui relie les valeurs. Vous pouvez toujours faire plusieurs énumérations si c'est plus approprié.

Vous avez seulement fait la moitié des changements pour être plus propre. La croissance de la méthode doit être modifié comme ceci:

static String grow(Fruits type) {
    return type.gimmeFruit();
}

Et Fruits devrait être renommé Fruit: une pomme est un fruit, pas un de fruits.

Si vous avez vraiment besoin de garder votre chaîne de types, puis de définir une méthode (dans l'énumération de la classe elle-même, par exemple) pour retourner le Fruit associé à chaque type. Mais la plupart du code, il faut utiliser des Fruits au lieu de String.

Je ne suis pas certain que j'allais utiliser les Énumérations ici. J'ai peut-être manqué quelque chose (?), mais je pense que ma solution devrait ressembler à quelque chose comme ceci, avec des classes séparées pour chaque type de fruit, le tout basé sur l'un des genres les fruits de la classe:

//Note: Added in response to comment below
public enum FruitType {
    WATERMELON,
    WHATEVERYOUWANT,
    ....
}


public class FruitFactory {

    public Fruit getFruitToGrow(FruitType type) {

        Fruit fruitToGrow = null;

        switch(type){
            case WATERMELON:
                fruitToGrow = new Watermelon();
                break;
            case WHATEVERYOUWANT:
                ...
            default:
                fruitToGrow = new Fruit();
        }

        return fruitToGrow;
    }
}


public class Fruit(){
    public void grow() {
        //Do other fruit growing stuff
    }
}



//Add a separate class for each specific fruit:
public class Watermelon extends Fruit(){
    @override
    public void grow(){
        //Do more specific stuff... 
    }
}

J'deuxième Sean Patrick Floyd sur que les énumérations sont le chemin à parcourir, mais voudrais ajouter que vous pouvez raccourcir votre code d'événement de plus en plus de façon spectaculaire à l'aide d'un système comme ceci:

enum Fruits {
   WATERMELON("watermelon fruit"),
   APPLE("apple fruit"); //...

   private final String gimme;

   private Fruits(String gimme) {
      this.gimme = gimme;
   }

   String gimmeFruit() { return this.gimme; }       
}

Aussi, la "croissance" de la méthode est douteuse. Ne devrait-il pas être quelque chose comme

public static String grow(Fruits f) {
   return f.gimmeFruit();
}

J'ai souvent de mettre en œuvre une méthode dans les énumérations de l'analyse d'une Chaîne de caractères et renvoie le correspondant constante enum. J'ai toujours le nom de cette méthode parse(String).

Parfois, je la surcharge de cette méthode pour analyser les enum constante par l'autre, compte tenu du type d'entrée, trop.

C'est la mise en œuvre est toujours le même:
Parcourir toutes les valeurs de l'enum() et revenir quand vous le frappez. Enfin faire un retour comme fallthrough - souvent spécifique constante enum ou null. Dans la plupart des cas, je préfère null.

public class FruitGrower {
    enum Fruit {
        WATERMELON("wtrmln") {
            @Override
            void grow() {
                //do watermelon growing stuff
            }
        },

        APPLE("ppl") {
            @Override
            void grow() {
                //do apple growing stuff
            }
        },

        PINEAPPLE("pnppl") {
            @Override
            void grow() {
                //do pineapple growing stuff
            }
        },

        ORANGE("rng") {
            @Override
            void grow() {
                //do orange growing stuff
            }
        },

        OTHER("") {
            @Override
            void grow() {
                //do other fruit growing stuff
            }
        };

        private String name;

        private Fruit(String name) {
            this.name = name;
        }

        abstract void grow();

        public static Fruit parse(String name) {
            for(Fruit f : values()) {
                if(f.name.equals(name)){
                    return f;
                }
            }

            return OTHER; //fallthrough value (null or specific enum constant like here.)
        }
    }


    public void growAFruit(String name) {
        Fruit.parse(name).grow();
    }
}

Si vous n'avez pas vraiment besoin de ce Fruit.OTHER de le supprimer. Ou comment un "Autre-fruits" pousse? oO
Retour null puis dans parse(String) méthode fallthrough une valeur null à vérifier avant d'appeler grow() dans growAFruit(String).

C'est une bonne idée d'ajouter @CheckForNull annotation à l' parse(String) méthode, puis.

La réponse à votre question est d'utiliser les énumérations, ou mieux encore, les usines et le polymorphisme, comme mentionné ci-dessus. Toutefois, si vous voulez vous débarrasser de commutateurs (qui est ce que votre if-else est vraiment en train de faire) complètement , un bon moyen, si pas le meilleur, afin de le faire est d'utiliser l'inversion de contrôle. Donc, je vous suggère d'utiliser le printemps, comme suit:

public interface Fruit {
   public void grow();
}

public class Watermelon implements Fruit {

   @Override
   public void grow()
   {
       //Add Business Logic Here
   }
}

Maintenant, créez le fruit de localisateur d'interface, comme suit:

public interface FruitLocator {

Fruit getFruit(String type);
}

Laisser la classe principale de disposer d'une référence à un FruitLocator objet, un setter pour elle, et il suffit d'appeler le getFruit commande:

private FruitLocator fruitLocator;

public void setFruitLocator (FruitLocator fruitLocator)
{
    this.fruitLocator = fruitLocator;
}

public void growAFruit(String type) {
    fruitLocator.getFruit(type).grow();
}

Maintenant vient la partie difficile. Définir votre FruitGrower classe comme un printemps de haricots, ainsi que votre FruitLocator et des Fruits:

<bean id="fruitGrower" class="yourpackage.FruitGrower">     
    <property name="fruitLocator" ref="fruitLocator" />
</bean>

<bean id="fruitLocator"
    class="org.springframework.beans.factory.config.ServiceLocatorFactoryBean">
    <property name="serviceLocatorInterface"
        value="yourpackage.FruitLocator" />
    <property name="serviceMappings" ref="locatorProperties" />
</bean>
<bean id="locatorProperties"
    class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="location" value="classpath:fruits.properties" />
</bean>

    <bean id="waterMelon" class="yourpackage.WaterMelon">       
</bean>

Seule chose qui reste à faire est de créer un fruits.les propriétés de fichier dans votre classpath et ajouter le type de grain de cartographie, comme suit:

wtrmln=waterMelon        

Maintenant, vous pouvez ajouter des fruits autant que vous le souhaitez, vous avez seulement besoin de créer un nouveau fruit de la classe, de la définir comme un haricot et ajouter un mappage de votre fichier de propriétés. Beaucoup beaucoup plus évolutif que la chasse pour if-else logique dans le code.

Je sais que cela peut sembler complexe au premier abord, mais je pense que le sujet serait incomplète sans parler de l'Inversion de Contrôle.

Bien, les enums code est sûrement plus. Ce que je suggère:

• Utiliser des Chaînes lorsque la logique est simple, petit, et sera utilisé 1 fois.
• Utiliser les Énumérations lorsque vous devez utiliser les constantes de nombreuses fois, d'ajouts ou de modifications sont possibles, ou lorsqu'ils sont mélangés dans un complexe de code de sorte qu'il est préférable de clarifier avec l'Enum.