Faut-il définir une valeur nulle/inconnue pour les enums Java ?

Question

Lorsque vous définissez un enum pour quelque chose qui peut être "indéfini" dans vos interfaces, devez-vous

• définir une valeur d'énumération distincte pour cela, ou
• utiliser simplement enumValue = null pour ces situations ?

Par exemple,

serviceX.setPrice(Prix priceEnum)

enum Price {
 CHEAP, EXPENSIVE, VERRRY_EXPENSIVE, UNKNOWN
}

et priceEnum.UNKNOWN si nécessaire

ou

enum Price {
 CHEAP, EXPENSIVE, VERRRY_EXPENSIVE
}

et priceEnum = null lorsque cela est nécessaire ?

Nous avons un petit débat sur ce sujet. Quelques points qui me viennent à l'esprit :

• L'utilisation de Price.UNKNOWN permet d'économiser du code "if (price == null)". Vous pouvez gérer toutes les valeurs de Price x dans un seul cas de commutation.
• Selon la technologie d'affichage, il peut être plus facile de localiser Price.UNKNOWN
• L'utilisation de Price.UNKNOWN entraîne un problème de "nombre magique" dans le code, selon moi. Ici, nous avons Price.UNKNOWN, ailleurs peut-être Color.UNDEFINED, Height.NULLVALUE, etc.
• L'utilisation de priceValue = null est plus uniforme avec la façon dont les autres types de données sont traités en Java. Nous avons Integer i = null, DomainObject x = null, String s = null pour les valeurs inconnues également, n'est-ce pas ?
• Price.UNKNOWN vous oblige à décider si la valeur nulle est autorisée de manière universelle pour tous les cas d'utilisation. Nous pouvons avoir la méthode Price getPrice() qui peut retourner Price.UNKNOWN et setPrice(Price p) qui n'est pas autorisée à accepter Price.UNKNOWN. Comme Price.UNKNOWN est toujours inclus dans les valeurs de l'enum, ces interfaces ont l'air un peu malpropres. Je sais que priceValue = null a le même problème (vous ne pouvez pas définir dans l'interface si null est accepté ou non) mais cela semble un peu plus propre et un peu moins trompeur( ?).

Answer 1

Il s'agit en fait d'un exemple d'application Modèle d'objet nul . IMHO il est toujours mieux d'avoir un objet factice plutôt que nul. Par exemple, vous pouvez ajouter des méthodes fictives à l'objet null plutôt que de disperser votre code avec des contrôles de nullité partout. Très pratique.

De même, le nom de la enum vous donne une sémantique supplémentaire : le prix est-il inconnu , indéfini no digne de confiance pas encore connu sous le nom de ? Et qu'est-ce que cela signifie si le prix est null ?

UPDATE : Comme Aaron Digulla fait remarquer que le modèle Null Object nécessite de la mémoire. Mais ce n'est pas vraiment le cas la plupart du temps. Dans l'implémentation traditionnelle, vous avez généralement un singleton pour l'objet Null utilisé partout car il n'y a pas besoin d'instances séparées. C'est encore mieux avec les enums car vous obtenez gratuitement la sémantique du singleton.

Un autre point est que null et la référence à un objet occupent la même quantité de mémoire (disons 4 octets sur une machine 32 bits). C'est l'objet référencé qui occupe un peu plus de mémoire. Mais s'il s'agit d'un singleton, il n'y a pratiquement pas de surcharge mémoire ici.

Answer 2

Je dirais que c'est Price.UNKNOWN si c'est une valeur valide pour un prix.

Je suis d'accord avec les inconvénients du traitement des références nulles que vous mentionnez, et je pense qu'ils motivent suffisamment la décision.

De nouveaux langages, comme Scala par exemple (et d'autres plus anciens, comme Haskell), s'éloignent des références nulles et utilisent des monades optionnelles / peut-être à la place... pour de bonnes raisons.

Answer 3

Cela dépend de l'utilisation que vous allez faire de cet enum. Si vous l'utilisez dans des déclarations switch/case, cela n'a pas d'importance. Si vous créez une ou plusieurs méthodes dans l'enum, vous devez définir UNKNOWN.

Par exemple, vous pouvez définir une méthode abstraite public abstract Icon icon();

dans votre enum, puis implémentez cette méthode pour chaque membre de Price. Vous voudrez probablement afficher un point d'interrogation pour un prix inconnu. Dans ce cas, il suffit d'implémenter la méthode icon() qui crée l'icône appropriée.

Answer 4

Il y a le Enum-Switch-Null-Trap . Il semble donc que, comme pour toute propriété qui est un objet, si elle n'existe pas alors elle est null .

Answer 5

La couleur ou la hauteur serait utilisée dans la logique du programme. Ils ne peuvent pas gérer avec une couleur non définie. Un prix est une donnée utilisateur et peut être inconnu. La couleur peut être une autre donnée utilisateur, mais pour être utilisée comme couleur dans le code, elle doit être définie.

Ainsi, le prix peut être UNKNOWN (au lieu de null), mais pas la couleur (null peut indiquer une erreur).