Plusieurs ENUMS VS ONE ENUM

La différence est que vous pouvez ajouter d'autres instances de signal sans modifier l'énum d'origine. Votre code peut fonctionner avec des instances de signal et des types différents peuvent être fournis. La même chose que l'interface pour les classes - vous donne une flexibilité, mais cela n'est utile que si vous en avez besoin. Dans votre cas, je ne vois pas beaucoup d'utilisation car l'interface est vide et que les énums mettent la mise en œuvre n'ont rien d'entre eux.

Vous pouvez vérifier ce site pour un bon exemple d'ENUM avec interfaces:

http://www.elikoff.net / 2011/06/15 / Java-Enums-Can-implément-implément-interfaces /

Ne soyez pas trop strict, voici mon interprétation de ce code. Appelons le propriétaire des flux réactifs Roland.

Au début Roland a besoin d'une interface commune pour tous les InboundSignals CODE> P>

static final class Request implements Signal {
    final long n;
    Request(final long n) { // every Request has different value of n
        this.n = n;
    }
};

Donc, depuis que je ne savais pas laquelle des réponses à approuver, j'ai envoyé l'auteur de la pièce de code et lui posa de ce qu'il pensait. Voici la conversation (les blocs sont de lui. Le texte normal est le mien):

salut michael,

Quelle est la différence avec une seule énumération alors? Vous n'auriez pas trois singletons mais toujours trois objets définis uniquement.:

sûr, cela pourrait être fait, mais je devrais alors inventer un nom pour cela (comme concretesignal), mon codage choisi évite que:) xxx

Je pense que c'est aussi thread-coffre-fort et si vous voulez vraiment avoir l'interface partagée, que vous pouvez partager avec des objets par exemple, vous pouvez le faire comme ceci: xxx

vous pouvez certainement faire comme vous l'avez fait ci-dessus, mais je dirais que ils [annuler, abonner, envoyer] ne sont pas plus concrets que la demande (qui est aussi un signal): https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/examples/src/main/java/org/reactiftreams/example/unicast/asynCiterAvablePublisher.java # L49

En outre, cela pourrait également encourager à utiliser les méthodes d'enum énumérer tous les signaux possibles, ce qu'il ne pouvait pas, car la demande est pas un signal. A du sens?

En effet à Scala, vous préférez le faire avec un objet, mais en Java, il est très rare de voir quelque chose comme votre implémentation. J'étais juste curieux que je manquais une caractéristique soignée à Java. Mais si je comprends bien, c'est parce que vous êtes plus confortable avec cette mise en œuvre, car il est plus proche de Scala, votre langue préférée?

Je suppose qu'il y a un peu de ça, mais le singleton-as-énumul-motif en Java est assez connu, alors la seule chose "bizarre" serait de avoir une "enum" distincte pour chacun d'annuler, abonnez-vous et envoyez, mais comme J'ai expliqué précédemment, car la demande ne peut pas être codée comme celle que je opté pour la version plus "scala-y".

Donc, si "Demande" n'aurait besoin d'aucun paramètre, j'aurais fait comme vous Suggestion: Enum Signal {Annuler, Demande, S'abonner, Envoyer}

Mystère résolu: -).

Ce que je pense que la seule raison d'utiliser l'interface avec Enum avec Enum, que certains signaux ont des données diffrentes que d'autres signaux, il est donc nécessaire de prolonger le type ENum pour y fixer des données.