例如，我们有一个具有不同角色的电脑游戏。 角色的性别将存储在“性别”字段中。 您可以使该字段为整数或字符串，但是优秀的程序员试图使对象的不正确状态无法表达，因此很可能会开始枚举。 现在要使性别错误的角色变得根本不可能！
在游戏中，有一个存储所有玩家的数据库，您还需要记录他们的性别。 最好不要将性别不正确的字符添加到数据库中，因为不仅代码可以使用它，其中没有为性别提供枚举的对象，而且为活着的人提供了枚举。 如您所知，在世人士努力将不需要在数据库中输入的信息输入数据库。
幸运的是，尤其是对于此类情况，许多DBMS还具有创建枚举类型的列的能力，从而限制了此类列中的数据可以具有的值的范围。 将利用经验丰富的开发人员的优势，他不希望自己的项目不是风水项目。
在客户端上，程序员也不是一个傻瓜，并且知道错误的状态必须是无法表达的，为此，字符的性别必须是枚举。
太好了！
但是，如果仔细观察，您会发现一个小缺陷，最终导致问题。 存储楼层的字段不是性别，而是性别，这意味着已经为其选择了游戏设计师。 迟早，他将发现与性别不同的是，实际上存在两种以上的性别，并且他将要添加GENERIC_TEEN性别。 然后每个人都会变得愚蠢。
客户端必须不断更新
第一个掉队的人是编写客户端代码的人，因为对于每次打喷嚏，性别参数的不正确值将从服务器开始。 而且，当服务器上出现一个带有性别的角色（客户端不知道客户端的存在）时，程序员所希望的游戏就不会启动。 现在，随着新性别的到来，有必要发布新版本的客户端并启动强制更新，我们都非常喜欢。
在枚举服务器上，这很好，因为如果在其中找到了一些未知值，那么显然这是一个错误，需要找到并解决，但在客户端上，出现未知值是一种常见情况，经常会在客户端的过时版本中发生，因此枚举的邪恶必须尽快消除和销毁。
新代码将无法与旧数据库一起使用
此外，根据最佳犬只繁殖者的建议，新代码应能够与旧数据方案配合使用，并且在这里证明，整个系统只有在代码中添加了新性别后才能崩溃。
因此，在枚举数据库中，它使我们感到困扰，在这种情况下，我们需要在字段中存储字符串，int或其他内容，如有必要，您可以在其中编写事先未提供的值。
有人会说：好的，好的，它损害了枚举客户端，并且在数据库中的干扰超过了它的帮助，但是枚举在服务器代码中非常有用。 他不会提出从服务器上的代码中删除枚举吗？ 会的！
旧代码将无法与新数据库一起使用
今天，建议程序员不仅编写代码以使其能够与旧数据库正常工作，而且还建议开发数据方案，以使稍稍过时的代码也可以正常工作。
而且，如果您在服务器上使用enum作为性别，那么只有在事实证明新代码出了点问题并且您需要立即将所有内容回滚到以前的版本并且新的性别已经输入数据库之后，一切都会再次崩溃。
因此，从服务器代码中获取带有经过测量的士兵脚步的枚举朝着最近的森林方向去某个地方，以免永不从那里返回，因为在错误的时间破坏系统的一切都是邪恶的，而邪恶在我们舒适的代码中没有地位。
所以也许锤击枚举并始终使用字符串？
简而言之，正如小熊维尼（Winnie Pooh）所说-这些都是某种错误的敌人，它们激起了程序员编写错误的代码！ 在枚举中，您需要放置多年来不可改变的真正不可动摇的基本事物，而不是每次发布都会增加或消失的性别！ 每个任务都有其自己的工具，枚举不是存储值所需要使用的工具，它的可能范围正在不断扩大。
如果变量只能采用一些先前已知的值，而这些值中未包含的所有内容都将导致错误，则使用枚举是一个好主意，但是如果不是，则如果意外值定期落入变量中，则使用枚举等于用脚射击自己，最好不要这样做，除非您当然是受虐狂。
这种特殊情况很有趣，因为没有什么预示可以将新值添加到枚举中，更不用说新值会定期出现的事实。 我们甚至怎么知道会有两个以上的性别？
因此，根据KISS原则，第一阶段的枚举是一个不错的选择。 经验丰富的程序员将制作枚举并解决，当出现附加值时，您需要立即运行枚举从代码中消失所必需的事件。
不幸的是，实践表明，实际上会有其他人参与添加新性别，而无需三思而后行，他会为枚举添加新含义，这将使您平静下来。 因此，如果有任何疑问，最好遵循一条简单的规则：将其存储在代码之外的某个位置，这意味着没有枚举，这就是重点。
因此，枚举根本不应该在性别相关代码中吗？
尽管我刚才已经说过，但是代码中的枚举仍然非常有用，即使它们包含属于数据库的值。 不仅需要使用它们来存储从数据库中拉出的值，还需要将来自数据库的值与所需值进行比较。 例如，当程序员想要写一个字符性别为GENERIC_TEEN的程序员时，他不能在清单中放酒精，则可以使用value方法创建一个枚举Gender，该方法返回一个字符串，并编写一个代码来检查字符是否具有性别字段和Gender.GENERIC_TEEN .value（），这样会很好，因为它不允许程序员在状态值中犯错误。
代码必须发展
随着时间的流逝，在某些时候为我们服务的决定可能会变得不舒服。 而且，您需要确保代码能够反映项目的当前状态，而不是拐杖，几年前在膝盖上创建的解决方案只能延伸到“现在和现在”。 否则，对于与项目有某种联系的每个人，无论是开发人员，测试人员还是直接用户，它将都是取之不尽，用之不竭的来源。