Mes collègues et moi avons discuté de la logique à Enums. Ma préférence personnelle est de pas avoir une sorte de logique dans Java Enums (bien que Java offre la capacité de le faire). La discussion dans ce casé a centré sur une méthode de commodité à l'intérieur de l'énuméro qui a renvoyé une carte: ma préférence personnelle consiste à extraire cela dans un service. L'argument pour avoir la méthode à l'intérieur de l'énumé centré sur la commodité. L'idée était que vous n'avez pas besoin d'aller à un service pour l'obtenir, mais peut interroger l'énum directement. Mon argument axé sur la séparation de la préoccupation et abstraite tout type de logique à un service. Je n'ai pas pensé que "commodité" était un argument fort pour mettre cette méthode à l'intérieur d'une énumération. du point de vue des meilleures pratiques, lequel est le meilleur? Ou est-ce qu'il s'agit simplement d'une question de préférence personnelle et de style de code?
6 Réponses :
Eh bien, j'ai déjà fait cela, mais cela ne veut certainement pas dire que c'est la "meilleure" chose à faire.
de mon point de vue, cependant, je préférerais avoir cette logique sur l'énum, pour la même raison pour laquelle vous ne déplacez pas une méthode de "Tostring" à un service. La logique ne concerne que l'énumement elle-même et sa propre représentation.
Je pense qu'il serait trompeur de déplacer une telle méthode à un service - en le plaçant sur l'enum, vous êtes à la hauteur du fait que l'énum a une méthode «Tomap». Quelqu'un qui ne connaissait pas le service et que je cherchais que l'énumé peut ne pas savoir que.
Cela aide également à l'achèvement automatique dans l'IDE - je peux frapper le ".". Clé et voir instantanément des méthodes fournies par l'objet.
Je ne peux voir aucune raison persuasive pourquoi c'est "bonne pratique" ... ou "mauvaise pratique" ... faire ce que vous suggérez.
Je suis enclin à aller pour l'argument de la commodité. Mais franchement, Ce n'est pas le genre de chose qu'il est productif de passer des journées d'homme à débattre ... imo.
J'étais sur le point de poster un commentaire disant «c'était probablement pendant le déjeuner»
Eh bien ... Manger Votre déjeuner est plus intéressant ... imo :-)
Je pense que cela dépend probablement de la préférence personnelle et de savoir si vous pensez que la logique pourrait changer à l'avenir.
Le meilleur étui d'utilisation pour Enum Logic (car il est joli statique) est destiné aux choses qui ne vont pas changer. La logique dans java.util.concurrent.timeunit est un très bon exemple de ceci: les facteurs de conversion entre les unités de temps sont bien définis et ne changeront jamais, c'est donc un bon candidat à la logique statique intégré dans l'énum.
J'ai essayé la logique dans Enums à quelques reprises, mais la seule chose que je suis vraiment vraiment heureuse, c'est quelque chose comme: généralement une fois que vous avez commencé à ajouter des variables d'instance / méthodes, vous devez probablement faire quelque chose avec une classe appropriée.
Je commencerais par la mettre dans l'énum. S'il y aura une seule méthode Tomap () dans le système, une classe supplémentaire est sûrement inutile et sera ennuyeuse.
Si j'avais beaucoup d'énumérums à partir de laquelle je veux créer une telle carte, ou peut-être anticiper cette situation, alors je vais créer une classe d'utilité statique et une méthode d'utilité généralisée pour le faire.
Mon opinion personnelle est la théorie des trampes pratiques.
EDIT: OH Attendez, il serait difficile de fournir une méthode d'utilité générique. Dans ce cas, si la méthode sera si spécifique, je vais certainement aller avec l'énum. Si j'étais le programmeur d'entretien, je serais très insatisfait si vous auriez une classe supplémentaire que je dois rechercher.
Si vous avez utilisé une stratégie pour déterminer ce qu'il faut mettre dans la carte, il devient trivial, mais ajoutant une dépendance à une énumération pour une autre interface / classe pour ces claques d'abus. Si j'étais un programmeur d'entretien, je serais heureux du niveau supplémentaire d'indirection, tout ce qui contribue à traiter ces cas de bord et des cas spéciaux que les cultures sont toujours utiles. Et s'ils n'avaient jamais eu besoin de ne jamais avoir remarqué / se soucié.
Comme tout ce qu'il dépend de l'utilisation, il existe des règles générales, mais la praticité devrait toujours gagner l'argument. Quelle est la carte utilisée? Auriez-vous déjà besoin de restreindre le contenu de la carte, par exemple Si la carte est utilisée pour remplir une liste déroulante, il est nécessaire de supprimer certains choix, disons que si certains supports ne manipulaient que certains types de paquets qu'une stratégie pourrait être utilisée pour peupler une carte, qui serait la mieux effectuée en dehors de l'énum.
Malgré cela, ma préférence serait d'avoir une création de la carte ailleurs, que le niveau supplémentaire d'indirection n'est jamais un obstacle à la flexibilité et pourrait économiser beaucoup de chagrin et ajoute de petits frais généraux maintenant. Et vous pouvez également le coder afin que vous puissiez obtenir des fonctionnalités similaires avec d'autres Enums.
Si les chaînes sont finales, envisagez de faire une carte immuable à l'heure initiale statique au lieu de rouler un à chaque fois que quelqu'un appelle Tomap ()