For example, we have a computer game with diverse characters. The gender of the character will be stored in the gender field. You can make this field an integer or a string, but a good programmer seeks to make the incorrect state of objects inexpressible, and therefore, most likely, will start enum for the floor. Now to make a character with the wrong gender is simply impossible!
And in the game there is a database in which all the players are stored, and there you also need to record what gender they are. It would be nice to make it impossible for a character with an incorrect gender to be added to the database, because not only the code will work with it, in which nothing except enum is provided for the sexes, but also living people. And living people, as you know, strive to enter into the database that which is not necessary to be entered there.
Fortunately, especially for such cases, in many DBMSs it is also possible to make columns of the enum type, thereby limiting the range of values that data in such a column can have. What will take advantage of an experienced developer who does not want his project to be something not for feng shui.
On the client, the programmer is also not a fool and also knows that incorrect states must be inexpressible, and for this the gender of the character must be enum.
Perfect!
However, if you look closely, you can find one small flaw, which ultimately leads to problems. The field in which the floor is stored is called not sex, but gender, which means that a game designer is already being selected for it. Sooner or later, he will find out that there are substantially more than two genders, unlike sexes, and he will want to add the GENERIC_TEEN gender. Then everyone will get stupid.
The client must be constantly updated
The first to fall are the guys who wrote the client code, because incorrect values of the gender parameter will start coming from the server for each sneeze. And when a character with a gender comes from the server about the existence of which the client does not know, then the game, as the programmer wanted on the client, simply will not start. Now, with the advent of new genders, it is necessary to release new versions of clients and launch forced updates, which we all love so much.
On the enum server, it’s good, because if some unknown value is found there, then this is clearly an error that needs to be found and fixed, but on the client, the appearance of an unknown value is a regular situation that will regularly happen on outdated versions of the client, and therefore there enum is evil that must be eradicated and destroyed as soon as possible.
New code will not be able to work with the old database
In addition, according to the recommendations of the best dog breeders, the new code should be able to work with the old data scheme, and here it turns out that the whole system can fall apart just because a new gender has been added to the code.
Therefore, enum bothers us in the database, and in this case we need to store in the field strings, or ints, or whatever, into which, if necessary, we can write a value that is not provided in advance.
And someone will say: okay, okay, it harms the enum client, and in the database it interferes more than it helps, but enum is of great benefit in the server code. He will not offer to remove enum from the code on the server? Will be!
Old code will not be able to work with the new database
Nowadays, the programmer is recommended not only to write the code so that it works normally with the old database, but also to develop the data scheme so that the slightly outdated code can also work normally with it.
And if you use enum on the server for gender, then everything will fall apart again, only after it turns out that something is wrong with the new code and you need to immediately roll back everything to the previous version, and the new genders are already in the database.
And therefore, enum from the server code, with a measured soldier's step, go somewhere in the direction of the nearest forest, so as never to return from there, because everything that can destroy the system at the wrong time is evil, and evil has no place in our cozy code.
So maybe hammer on enum and always use strings?
In short, as Winnie the Pooh would say - these are some kind of wrong enamy, and they provoke the programmer to write the wrong code! In enum, you need to put really unshakable and fundamental things that have not changed over the years, and not genders that add and disappear every release! Each task has its own tool, and enum is not the tool that you need to use to store values, the possible spectrum of which is constantly expanding.
If a variable can take only some previously known values and everything that is not included in these values should lead to an error, then using enum is a good idea, but if it is not, if the unexpected values regularly fall into the variable, then use enum is equal to shoot yourself in the foot, and it is better not to do this, unless you are, of course, a masochist.
This particular situation is interesting because nothing foreshadowed the addition of new values to the enum, not to mention the fact that new values will appear regularly. How did we even know that there would be more than two sexes?
Therefore, according to the KISS principle, enum in the first stage is a good and right choice. An experienced programmer will make enum and fix that, when an additional value appears, you need to immediately start the activities necessary for enum to disappear from the code.
Unfortunately, practice shows that in reality someone else will be involved in adding a new gender, and without thinking twice, he will add a new meaning to enum, and this will calm down. So if there is any doubt, it is better to follow a simple rule: stored somewhere, except for the code - it means not enum, and that’s the point.
So, enum should not be in the gender-related code at all?
Despite what I just said, enum in the code can still be very useful, even if they contain values that fall into the database. It is not only necessary to use them in order to store the values that are pulled from the database, it is necessary to compare what came from the database with the desired value. For example, when a programmer wants to write that if the character’s gender is GENERIC_TEEN, then he can’t put alcohol in his inventory, you can create an enum Gender with the value method that returns a string, and write a code that will check if the character has a gender field and Gender.GENERIC_TEEN .value () and this will be good, because it will not allow the programmer to make a mistake in the status value.
Code must evolve
Solutions that have served us well at some point may become uncomfortable over time. And you need to make sure that the code reflects the current state of the project, and not be a set of crutches, with which the solution created on the knee a couple of years ago, stretches to the "here and now." Otherwise, it will be an inexhaustible source of fakap and lulz for everyone who is somehow connected with the project, whether it is a developer, tester or direct consumer.