What is Good is a Matter of Opinion

Creating an enum class for each data type creates multiple classes. The more data types you add to a program, the more classes you must create to accommodate the enum pattern. Some developers might consider this highly organized, while others might feel overwhelmed or annoyed that they must check multiple files for something as simple as a data comparison. Enum classes and if-else statements are both acceptable solutions to this problem. In larger programs, the enum approach is still manageable even with more classes because each class has a unique name. The multiple enum classes can become a problem if you later need to change 100 classes to alter how all data types are handled, but even this can be managed.

To modify Version 4 of the final software, I would abstract the logic of the enum class and separate the type values into their own classes. This would allow me to have a central place to add additional logic to all enums. Alternately, to modify version 3, I would not have used enum classes. I would have simply added if-else statements, which would be sufficient. 

In version 4 of your final code modification, you used a simple if-else statement to restrict the user input for the conditionals instead of creating an enum.

According to your definition of "good" software, an academic answer to improve this program could recommend utilizing an enum instead of an if-statement to validate or restrict the user input. While it is good practice to put checks and balances in place that inform the user when something is wrong, how you implement that check is a developer preference.

A minor development choice does not determine if a program is adequate or good. Test and Quality Assurance determine if a program is good. In this example, we magnify a small part of a tiny piece of code and make it a big issue when it is merely a small design choice in a large application. I would not consider a program utilizing an enum approach to be "good" software solely because it follows a software development principle in academia. Similarly, I would not define a program using if-else statements instead of enums to be "only adequate" software.

When you reach a certain point in your programming journey, you realize the principles you choose to use bend towards your interests. For example, if you love coding in another language, you wouldn't only code in Java, solely, because it inherently follows strict programming principles. A similar debate in the React community exists regarding TypeScript, I enjoy studying other developer's programs written in TypeScript, but it is my personal preference to write programs in regular React because I can resolve strict type-checking issues differently. I could work on a TypeScript project but prefer to gravitate toward my interests. If you do not prioritize your interests, you will fail to gain depth of knowledge in the areas you want to explore, and you will get stuck on projects you do not enjoy. In Software Development, time is money, and the intended purpose of a program dictates how much effort and resources a developer can use towards solving a problem. 

Learning curves and extra code cost money. If I started working on a project and saw it used enums, I would look it up and continue following that pattern. But if a program didn't already use enums, I would not have gone out of my way to use enums to fix this problem. I like your approach and could expand from it even though I would have originally approached it differently. This is what it means to be on a team full of people with different personalities and interests.