Par exemple, nous avons un jeu informatique avec des personnages divers. Le sexe du personnage sera enregistré dans le champ genre. Vous pouvez faire de ce champ un entier ou une chaîne, mais un bon programmeur s'efforce de rendre inexactible l'état incorrect des objets et, par conséquent, très probablement, commencera l'énumération pour le sol. Maintenant, faire un personnage avec le mauvais sexe est tout simplement impossible!
Et dans le jeu, il y a une base de données dans laquelle tous les joueurs sont stockés, et là, vous devez également enregistrer de quel sexe ils sont. Ce serait bien de rendre impossible pour un personnage avec un sexe incorrect d'être ajouté à la base de données, car non seulement le code fonctionnera avec lui, dans lequel rien sauf enum est fourni pour les sexes, mais aussi pour les personnes vivantes. Et les gens vivants, comme vous le savez, s'efforcent d'entrer dans la base de données ce qui n'est pas nécessaire pour y être entré.
Heureusement, en particulier pour de tels cas, dans de nombreux SGBD, il est également possible de créer des colonnes du type enum, limitant ainsi la plage de valeurs que peuvent contenir les données d'une telle colonne. De quoi profiter d'un développeur expérimenté qui ne veut pas que son projet ne soit pas pour le feng shui.
Sur le client, le programmeur n'est pas non plus un idiot et sait également que les états incorrects doivent être inexprimables, et pour cela le sexe du personnage doit être énuméré.
Parfait!
Cependant, si vous regardez attentivement, vous pouvez trouver un petit défaut, ce qui conduit finalement à des problèmes. Le champ dans lequel le sol est stocké n'est pas appelé sexe, mais sexe, ce qui signifie qu'un concepteur de jeu est déjà sélectionné pour cela. Tôt ou tard, il découvrira qu'il y a sensiblement plus de deux sexes, contrairement aux sexes, et il voudra ajouter le genre GENERIC_TEEN. Ensuite, tout le monde deviendra stupide.
Le client doit être constamment mis à jour
Les premiers à tomber sont les gars qui ont écrit le code client, car des valeurs incorrectes du paramètre de genre commenceront à provenir du serveur pour chaque éternuement. Et quand un personnage avec un sexe vient du serveur sur l'existence dont le client ne sait pas, alors le jeu, comme le programmeur le voulait sur le client, ne démarre tout simplement pas. Maintenant, avec l'avènement de nouveaux genres, il est nécessaire de publier de nouvelles versions de clients et de lancer des mises à jour forcées, que nous aimons tous tellement.
Sur le serveur enum, c'est bien, car si une valeur inconnue y est trouvée, il s'agit clairement d'une erreur qui doit être trouvée et corrigée, mais sur le client, l'apparition d'une valeur inconnue est une situation régulière qui se produira régulièrement sur des versions obsolètes du client, et donc il y a un mal qui doit être éradiqué et détruit dès que possible.
Le nouveau code ne pourra pas fonctionner avec l'ancienne base de données
De plus, selon les recommandations des meilleurs éleveurs de chiens, le nouveau code devrait pouvoir fonctionner avec l'ancien schéma de données, et il s'avère ici que l'ensemble du système ne peut s'effondrer que parce qu'un nouveau sexe est ajouté au code.
Par conséquent, dans la base de données enum, cela nous dérange et dans ce cas, nous devons stocker dans le champ des chaînes, ou des entiers, ou quoi que ce soit, dans lequel, si nécessaire, vous pouvez écrire une valeur qui n'est pas fournie à l'avance.
Et quelqu'un dira: d'accord, d'accord, cela nuit au client enum, et dans la base de données, il interfère plus qu'il n'aide, mais l'énumération est très utile dans le code du serveur. Il ne proposera pas de supprimer l'énumération du code sur le serveur? Sera!
L'ancien code ne pourra pas fonctionner avec la nouvelle base de données
Aujourd'hui, il est recommandé au programmeur non seulement d'écrire le code afin qu'il fonctionne normalement avec l'ancienne base de données, mais également de développer le schéma de données afin que le code légèrement obsolète puisse également fonctionner normalement avec elle.
Et si vous utilisez enum sur le serveur pour le sexe, tout s'effondrera à nouveau, seulement après qu'il s'est avéré que quelque chose ne va pas avec le nouveau code et que vous devez immédiatement tout restaurer à la version précédente, et les nouveaux genres sont déjà entrés dans la base de données.
Et par conséquent, l'énumération du code du serveur avec le pas d'un soldat mesuré va quelque part en direction de la forêt la plus proche, afin de ne jamais revenir de là, car tout ce qui peut détruire le système au mauvais moment est mauvais, et le mal n'a pas sa place dans notre code confortable.
Alors peut-être marteler sur enum et toujours utiliser des chaînes?
En bref, comme dirait Winnie l'Ourson - ce sont des sortes d'énamies erronées, et elles provoquent le programmeur à écrire le mauvais code! Dans l'énumération, vous devez mettre des choses vraiment inébranlables et fondamentales qui n'ont pas changé au fil des ans, et non des genres qui s'ajoutent et disparaissent à chaque sortie! Chaque tâche a son propre outil, et l'énumération n'est pas l'outil que vous devez utiliser pour stocker des valeurs, dont le spectre possible est en constante expansion.
Si une variable ne peut prendre que certaines valeurs précédemment connues et que tout ce qui n'est pas inclus dans ces valeurs devrait conduire à une erreur, alors enum est une bonne idée, mais si ce n'est pas le cas, si les valeurs inattendues tombent régulièrement dans la variable, alors utilisez enum est égal à se tirer une balle dans le pied, et il vaut mieux ne pas le faire, sauf si vous êtes, bien sûr, un masochiste.
Cette situation particulière est intéressante car rien ne laissait présager l'ajout de nouvelles valeurs à l'énumération, sans parler du fait que de nouvelles valeurs apparaîtront régulièrement. Comment savions-nous même qu'il y aurait plus de deux sexes?
Par conséquent, selon le principe KISS, l'énumération dans la première étape est un bon et bon choix. Un programmeur expérimenté fera une énumération et corrigera que lorsqu'une valeur supplémentaire apparaît, vous devez exécuter immédiatement les événements nécessaires pour que l'énumération disparaisse du code.
Malheureusement, la pratique montre qu'en réalité quelqu'un d'autre sera impliqué dans l'ajout d'un nouveau genre, et sans y réfléchir à deux fois, il ajoutera un nouveau sens à l'énumération, et cela se calmera. Donc, en cas de doute, il est préférable de suivre une règle simple: stockée quelque part autre que le code - donc, pas un ENUM, et sur ce point.
Donc, enum ne devrait pas du tout être dans le code lié au genre?
Malgré le fait que je viens de le dire, l'énumération dans le code peut toujours être très utile, même si elle contient des valeurs qui tombent dans la base de données. Il n'est pas seulement nécessaire de les utiliser pour stocker les valeurs extraites de la base de données, il est nécessaire de comparer ce qui provient de la base de données avec la valeur souhaitée. Par exemple, lorsqu'un programmeur veut écrire que si le sexe du personnage est GENERIC_TEEN, il ne peut pas mettre d'alcool dans son inventaire, vous pouvez créer un enum Gender avec la méthode value qui renvoie une chaîne et écrire un code qui vérifiera si le personnage a un champ gender et Gender.GENERIC_TEEN .value () et il sera bon, car il ne permettra pas au programmeur de faire une erreur au sens du statut.
Le code doit évoluer
Les décisions qui nous ont bien servis à un moment donné peuvent devenir inconfortables avec le temps. Et vous devez vous assurer que le code reflète l'état actuel du projet, et ne pas être un ensemble de béquilles, avec lequel la solution créée sur le genou il y a quelques années, s'étend jusqu'à «ici et maintenant». Sinon, ce sera une source inépuisable de fakap et de lulz pour tous ceux qui sont en quelque sorte liés au projet, qu'il s'agisse d'un développeur, d'un testeur ou d'un consommateur direct.