Comment fournir des implémentations pour les valeurs enum en Java?

Bien que je doute que cela puisse être restreint au moment de la compilation. Un moyen plus propre d'implémenter quelque chose de similaire serait d'utiliser switch ici:

switch (x.getDateType()) {
    case MONDAY: // do something
        break;
    case SUNDAY: // do something
        break;
    default:
        throw new CustomException("No implementations yet for :" + x.getDateType()); 
}

Une énumération était censée contenir les valeurs finales (statiques) au moment de la compilation, donc ajouter dynamiquement plus de valeurs est impossible (il suffit de le mettre là-bas). Quant à l'autre partie de votre question, comme @nullpointer l'a souligné, il est préférable d'utiliser la clause switch . Outre l'amélioration de la clarté du code, le compilateur avertit s'il y a des valeurs d'énumération pour lesquelles aucune instruction case n'est déclarée (c'est-à-dire, étant donné que vous omettez default )

Je ne suis pas non plus sûr que la conception d'énumérations pour l'extension par l'utilisateur soit une bonne idée. C'est statique, comme l'a déclaré @Garikai. Cela conduira à une odeur de code.

Si vous souhaitez avoir une option facile pour étendre le mappage d'énumération à fonction, je proposerais Map map = new EnumMap (DateType.class); et puis utilisez getOrDefault pour vous assurer que vous obtiendrez une sortie.

La vraie réponse est: ne faites pas cela.

Si vous avez un "type" et que vous savez que ce "type" verra de nouvelles incarnations au fil du temps, qui nécessitent un comportement différent, alors la réponse est d'utiliser une classe abstraite et un polymorphisme.

Peu importe que vous utilisiez des chaînes if / else ou des instructions switch: l'idée que vous avez quelque chose comme:

if (someObject.getSomething() == whatever) { then do this } else { that }

est une mauvaise pratique!

Si c'est le cas, vous devriez utiliser une telle instruction switch dans une fabrique pour renvoyer différentes instances de sous-classes, pour ensuite appeler des méthodes "courantes" sur de tels objets.

Votre approche actuelle est A) d'externaliser les connaissances sur l'état interne et B) d'appliquer également les dépendances de plusieurs manières.

C'est ainsi que le code spaghetti commence! Mieux vaut prendre du recul et réfléchir à d'autres moyens de résoudre ce problème en POO!

Une alternative à l'option de nullpointer est de mettre cette logique dans l'énumération elle-même, en supposant que cela a du sens dans votre conception (si cette responsabilité peut résider avec le type de jour enum).

x.getDateType().processSomeAction(inputIfApplicable);

Cela garantira que la nécessité de fournir une implémentation spécifique à la journée est évidente pour les développeurs qui apportent des modifications à DayType .

Et l'appelant aura juste besoin de:

public enum DayType {
    SUNDAY {
        @Override
        void processSomeAction(Object input) {
            super.processSomeAction(input);
            // process action with SUNDAY-specific logic
        }
    },

    MONDAY;

    //can be made abstract if there's no default implementation
    void processSomeAction(Object input) {
        // process action with default logic
    }
}

Vous pouvez créer une interface qui sera implémentée par votre classe Enum. Dans ce cas, toutes les énumérations doivent implémenter la méthode dans l'interface.

public enum DateType implements DateTypeInterface {

    SUNDAY {
        @Override
        public void checkCondition() {
            System.out.println("Implement Sunday logic");
        }
    },
    MONDAY {
        @Override
        public void checkCondition() {
            System.out.println("Implement Monday logic.");
        }
    }
}


public interface DateTypeInterface {

     public void checkCondition();
}

Je ne pense pas que vous ayez une option au moment de la compilation pour appliquer votre politique. Ce que je suggérerais, c'est de créer une interface (quelque chose comme DateTypeAction ) avec une seule méthode (par exemple action () ) et ensuite une Factory qui produit des implémentations concrètes basées sur une valeur de votre DateType (quelque chose comme DateTypeActionFactory.getDateTypeAction (DateType dateType) ). Lors de votre phase d'initialisation, vous pouvez parcourir toutes les valeurs de votre DateType ( DateType.values ​​() ) et vérifier qu'il existe une implémentation non nulle de DateTypeAction dans votre DateTypeActionFactory pour chaque valeur. Si vous trouvez une implémentation manquante pour une ou plusieurs valeurs, lancez une exception avec un message d'erreur explicite indiquant qu'une ou plusieurs implémentations sont manquantes et échouent au démarrage de votre application. Cela semble un modèle raisonnable.

BTW si vous utilisez ce modèle, j'ai une recommandation: j'ai écrit une bibliothèque java open source appelée MgntUtils qui fournit un cadre simple (très bien adapté pour une utilisation avec Spring) qui a un modèle d'usine auto-remplissant. C'est à dire. vous pouvez créer une interface et une bibliothèque d'extension d'usine pour les classes parentes, puis chaque implémentation de votre interface sera automatiquement insérée dans votre usine avec un nom prédéfini. Je l'ai utilisé plusieurs fois et je l'ai trouvé très pratique. Voici le lien vers l'article décrivant l'ensemble de la bibliothèque: MgntUtils Bibliothèque Java Open Source avec filtrage de trace de pile, analyse Silent String, convertisseur Unicode et comparaison de version . Cherchez le paragraphe

Gestion du cycle de vie (usines auto-instanciées)

pour une brève explication de la fonctionnalité. Vous pouvez lire ici toute l’idée de la fonctionnalité: Accès non intrusif aux Beans "Orphaned" dans le framework Spring . Les deux articles expliquent également où trouver la bibliothèque, mais voici les liens directs: Maven Central Repository et Github . La bibliothèque est livrée avec javadoc bien écrit

Cette réponse se développe sur certaines des autres réponses ici promouvant l'utilisation du polymorphisme.

Ce que j'essaie généralement de faire pour éviter d'avoir un commutateur / conditionnel croissant quelque part, est d'ajouter une méthode d'identification à l'interface:

private DayProcessor[] dayProcessors = new DayProcessor[] {new MondayProcessor(), new SundayProcessor()};

Ensuite, je crée un composant d'usine avec toutes les implémentations de DayProcessor disponibles câblées par Spring:

@Component
public class DayProcessorFactory {

    @Autowired
    private List<DayProcessor> dayProcessors;

    public DayProcessor create(Day day) {
        for (DayProcessor dayProcessor: dayProcessors) {
            if (dayProcessor.day().equals(day)) {
                return dayProcessor;
            }
        }
        // DayNotFoundException extends RuntimeException
        throw new DayNotFoundException(String.format("No DayProcessor found for day %s", day));
    }
}

Ceci est une forme du modèle de stratégie .

Un Une autre façon de répertorier tous les jours est de les énumérer (mais vous devrez ensuite mettre à jour la liste lorsqu'un nouveau jour est créé):

public enum Day {
    SUNDAY, MONDAY
}

public interface DayProcessor {

    Day day();

    // I don't know what Days are supposed to do exactly
    Object process(Object input); 
}