Questions tagged «enum»

我已经看到了许多类似这样的问题，要求提供有关如何在数据库中存储枚举的建议。但是我不知道你为什么要这么做。假设我们有一个Person带有gender字段和一个Gender枚举的实体。然后，我的人员表具有一列性别。 除了强制正确性的明显原因外，我不明白为什么我会创建一个额外的表gender来映射应用程序中已有的内容。我真的不喜欢重复。

69 database  enum 

一个enum X : int（C＃）或enum class X : int（C ++ 11）是具有一个隐藏的内部场类型int，可容纳任何值。另外，X在枚举上定义了许多预定义的常量。可以将枚举转换为其整数值，反之亦然。在C＃和C ++ 11中都是如此。 在C＃中，按照Microsoft的建议，枚举不仅用于保存单个值，而且还用于保存标志的按位组合。此类枚举（通常但并非必须）用[Flags]属性修饰。为了简化开发人员的工作，按位运算符（OR，AND等）被重载，因此您可以轻松地执行以下操作（C＃）： void M(NumericType flags); M(NumericType.Sign | NumericType.ZeroPadding); 我是一位经验丰富的C＃开发人员，但是现在仅对C ++进行了几天的编程，并且不了解C ++约定。我打算以与C＃中使用的完全相同的方式使用C ++ 11枚举。在C ++ 11中，作用域枚举上的按位运算符没有重载，因此我想重载它们。 这引发了一场辩论，意见似乎在以下三种选择之间有所不同： 枚举类型的变量用于保存位字段，类似于C＃： void M(NumericType flags); // With operator overloading: M(NumericType::Sign | NumericType::ZeroPadding); // Without operator overloading: M(static_cast<NumericType>(static_cast<int>(NumericType::Sign) | static_cast<int>(NumericType::ZeroPadding))); 但这会违背C ++ 11范围枚举的强类型枚举哲学。 如果要存储枚举的按位组合，请使用纯整数： void …

60 c++  c++11  enum  bitwise-operators 

假设我提供4种服务类型（它们不太可能经常更改）： 测试中 设计 程式设计 其他 假设我有60-80个实际服务，每个服务都属于上述类别之一。例如，“服务”可以是“使用技术A的测试程序”，并且类型为“测试”。 我想将它们编码到数据库中。我想出了一些选择： 选项0： 使用VARCHAR直接直接编码的业务类型为字符串 选项1： 使用数据库enum。但是，枚举是邪恶的 选项2： 使用两个表： service_line_item (id, service_type_id INT, description VARCHAR); service_type (id, service_type VARCHAR); 我什至可以享受参照完整性： ALTER service_line_item ADD FOREIGN KEY (service_type_id) REFERENCES service_type (id); 听起来不错，是吗？ 但是我仍然必须对事物进行编码并处理整数，即在填充表时。或者在填充或处理表时必须创建精心设计的程序或数据库结构。即，在直接处理数据库或在编程端创建新的面向对象的实体并确保我正确操作它们时，可以使用JOIN。 选项3： 不使用enum，不使用两个表，而只使用一个整数列 service_line_item ( id, service_type INT, -- use 0, 1, 2, 3 (for service …

38 database-design  efficiency  enum  normalization 

我在这里阅读一些代码，发现一个枚举用于存储html标签的名称。为什么我们需要这样做？使用此策略有什么好处？ 我知道枚举在编译或静态类型的语言中有多么有用，但是当我看到动态类型的语言中的枚举时，我会感到好奇，就像上面显示的示例代码一样。因此，问题基本上可以归结为为什么我们需要使用动态类型语言的枚举，或者根本不需要它们？

32 javascript  programming-practices  encapsulation  enum 

我正在开发一个简单的API，我想将其用于自己的客户端，并在将来向公众开放。我有可以具有不同“类型”的“项目”对象。目前，该类型是C“ typedef枚举”： typedef enum { ItemTypeBool, ItemTypeNumber, ItemTypeDate, } ItemType; （我将来可能会添加一些） 我想知道我是否应该将其转换为整数或定义的“字符串”。JSON为： 对于整数： { "name": "The name", "type": 0, ... } 对于字符串： { "name": "The name" "type": "boolean" ... } 我想知道是否有最佳实践。保留整数将稍微简化代码并减少带宽，但是字符串对于开发人员来说更容易记住。我记得我在一个项目上工作，我必须记住1 =图像，2 =音频，3 = html等。。。这没有任何实际意义。 所以我问你，如果你知道我应该考虑的其他方面。

32 api  patterns-and-practices  enum 

考虑下面的示例。对ColorChoice枚举的任何更改都会影响所有IWindowColor子类。 枚举会导致界面脆弱吗？是否有比枚举更好的东西可以提供更多的多态灵活性？ enum class ColorChoice { Blue = 0, Red = 1 }; class IWindowColor { public: ColorChoice getColor() const=0; void setColor( const ColorChoice value )=0; }; 编辑：很抱歉使用颜色作为我的示例，这不是问题所在。这是一个不同的示例，它避免出现红色鲱鱼，并提供有关灵活性的更多信息。 enum class CharacterType { orc = 0, elf = 1 }; class ISomethingThatNeedsToKnowWhatTypeOfCharacter { public: CharacterType getCharacterType() const; void setCharacterType( const CharacterType …

17 design-patterns  c++  interfaces  enum  abstract-class 

困境 我已经阅读了很多有关面向对象实践的最佳实践书籍，几乎我读过的每一本书都有一部分内容，他们说枚举是一种代码味道。我认为他们已经错过了解释枚举何时有效的部分。 因此，我正在寻找准则和/或用例，其中枚举不是代码的味道，而实际上是有效的构造。 资料来源： “根据经验，枚举是代码的味道，应将其重构为多态类。[8]” Seemann，Mark，依赖注入，.Net，2011年，第2页。342 [8] Martin Fowler等人，《重构：改进现有代码的设计》（纽约：Addison-Wesley，1999年），第82页。 语境 我陷入困境的原因是交易API。通过以下方法，他们给了我Tick数据流： void TickPrice(TickType tickType, double value) 哪里 enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... } 我尝试过围绕该API进行包装，因为打破更改是该API的生活方式。我想跟踪包装器上最后收到的刻度线类型的值，并且通过使用ticktypes字典来做到这一点： Dictionary<TickType,double> LastValues 在我看来，如果将它们用作键，这似乎是对枚举的正确使用。但是我有第二个想法，因为我确实有一个地方可以根据这个集合做出决定，而且我想不出一种消除消除switch语句的方法，我可以使用一个工厂，但是那个工厂仍然会有一个在某处切换语句。在我看来，我只是在移动东西，但仍然闻起来。 找到枚举的不容易，但是要做到的却不那么容易，如果人们可以分享他们的专业知识，利弊，我将不胜感激。 第二个想法 有些决定和行动是基于这些决定和行动的TickType，我似乎想不出消除枚举/切换语句的方法。我能想到的最干净的解决方案是使用工厂并返回基于的实现TickType。即使那样，我仍然会有一个switch语句，该语句返回接口的实现。 下面列出的是示例类之一，在其中我怀疑自己可能使用的枚举错误： public class ExecutionSimulator { Dictionary<TickType, double> LastReceived; void ProcessTick(TickType tickType, double value) { //Store Last Received …

17 c#  design-patterns  object-oriented  refactoring  enum 

如果您有一个仅带有值的枚举（没有任何方法可以像Java中那样），并且此枚举是系统业务定义的一部分，那么应该为它编写单元测试吗？ 我一直认为应该编写它们，即使它们看起来很简单而且很多余，但我认为应该在测试中明确编写与业务规范有关的内容，无论它是使用unit / integration / ui / etc编写的。测试或使用语言的类型系统作为测试方法。因为从业务的角度来看，枚举（例如Java中）必须具有的值不能使用类型系统进行测试，所以我认为应该为此进行单元测试。 这个问题是不是类似于这一个，因为它没有解决同样的问题我的。在该问题中，存在一个业务功能（savePeople），而该人员正在查询内部实现（forEach）。在那里，有一个中间业务层（该功能可节省人员），封装了语言构造（forEach）。这里的语言构造（枚举）是用于从业务角度指定行为的一种。 在这种情况下，实现细节与数据的“真实性质”相吻合，即：（在数学意义上）一组值。您可以说使用了一个不可变的集合，但是相同的值仍然应该在那里存在。如果使用数组，则必须执行相同的操作来测试业务逻辑。我认为这里的难题在于，语言结构与数据的性质非常吻合。我不确定我是否正确解释了自己

15 unit-testing  testing  type-systems  enum 

如果我使用switch语句来处理枚举（属于我的班级）中的值，并且每个可能的值都有一个大小写，是否值得添加代码来处理“默认”大小写？ enum MyEnum { MyFoo, MyBar, MyBat } MyEnum myEnum = GetMyEnum(); switch (myEnum) { case MyFoo: DoFoo(); break; case MyBar: DoBar(); break; case MyBat: DoBat(); break; default: Log("Unexpected value"); throw new ArgumentException() } 我不认为这是因为永远无法到达此代码（即使使用单元测试也是如此）。我的同事不同意并认为这可以保护我们免受因将新值添加到MyEnum而导致的意外行为。 社区，你怎么说？

15 unit-testing  maintenance  enum 

传统上，单例通常实现为 public class Foo1 { private static final Foo1 INSTANCE = new Foo1(); public static Foo1 getInstance(){ return INSTANCE; } private Foo1(){} public void doo(){ ... } } 使用Java的枚举，我们可以实现单例为 public enum Foo2 { INSTANCE; public void doo(){ ... } } 与第二版一样出色，它有什么缺点吗？ （我考虑了一下，我会回答我自己的问题；希望您有更好的答案）

14 java  singleton  enum 

几次我见过人们对枚举常量使用标题大小写或什至所有小写字母命名，例如： enum Color { red, yellow, green; } throw new IllegalStateException("Light should not be " + color + ".")例如，如果要这样做，这使得使用它们的字符串形式变得简单容易。 如果枚举是private，这似乎可以接受，但我仍然不喜欢它。我知道我可以使用String字段创建一个枚举构造函数，然后重写toString以返回该名称，如下所示： enum Color { RED("red"), YELLOW("yellow"), GREEN("green"); private final String name; private Color(String name) { this.name = name } @Override public String toString() { return name; } } 但是，看那还要多久。如果您有一堆小的枚举要保持简单，那么继续这样做很烦人。可以在这里只使用非常规大小写格式吗？

14 java  conventions  enum 

我的理解是，[Flag]枚举通常用于可以组合的事物，其中各个值并不相互排斥。 例如： [Flags] public enum SomeAttributes { Foo = 1 << 0, Bar = 1 << 1, Baz = 1 << 2, } 凡SomeAttributes值可以是一个组合Foo，Bar和Baz。 在更复杂的现实场景中，我使用一个枚举来描述DeclarationType： [Flags] public enum DeclarationType { Project = 1 << 0, Module = 1 << 1, ProceduralModule = 1 << 2 | Module, ClassModule = 1 …

12 c#  .net  readability  enum 

我是一个有抱负的游戏开发人员，我偶尔从事独立游戏的工作，有一段时间我一开始似乎做不好，但是我真的想从这里的一些经验丰富的程序员那里得到答案。 假设我有一个名为的文件enumList.h，其中声明了我想在游戏中使用的所有枚举： // enumList.h enum materials_t { WOOD, STONE, ETC }; enum entity_t { PLAYER, MONSTER }; enum map_t { 2D, 3D }; // and so on. // Tile.h #include "enumList.h" #include <vector> class tile { // stuff }; 主要思想是，我在1个文件中声明游戏中的所有枚举，然后在需要使用某个枚举时将其导入，而不是在需要使用的文件中声明该枚举。我这样做是因为它使事情变得干净，我可以在一个地方访问每个枚举，而不必只打开页面来访问一个枚举。 这是不好的做法吗？它会以任何方式影响性能吗？

12 c++  programming-practices  enum 

我正在微服务环境中开发一项新服务。这是一个REST服务。为了简单起见，假设路径为：/ historyBooks 此路径的POST方法将创建一个新的历史记录。 假设一本历史书涵盖了一个或多个历史时期。 为简便起见，我们假设我们只有以下人类历史时代： 古 后古典 现代 在我的代码中，我想用来表示它们enum。 方法的主体（有效负载）为JSON格式，并且应包含字段名称eras。此字段是era本书涵盖的值列表。 身体可能看起来像： { "name": "From the cave to Einstein - a brief history review", "author": "Foo Bar", "eras": ["Ancient", "Post Classical", "Modern"] } 在此特定服务中，业务逻辑是： 如果输入中未提供任何时代，则认为本书涵盖了所有时代。 在API审查中，提出了一个建议：为ERAS枚举 包含另一个值ALL，以明确表明已覆盖所有时代。 我认为它有一些优点和缺点。 优点： 显式输入 缺点： 如果提供了列表中的两项，请说ALL和Ancient-从应用程序中获取什么？我想这ALL应该覆盖其他值，但这是新的业务逻辑。 如果我运行查询，对于涵盖特定时代的图书，我将如何代表涵盖所有时代的图书？如果ALL还用于输出（使用相同的逻辑），则用户有责任将其解释ALL为["Ancient", "Post Classical", "Modern"]。 我的问题 我认为拥有新事物ALL比根本没有造成更多的混乱。 你怎么看？您是否要添加此ALL值或不使用它而保留API？

11 rest  api  json  enum 

我目前正在开发一个webapp，我们经常需要根据要返回给用户的页面来调整一些服务器逻辑。 每个页面都有一个4个字母的页面代码，这些页面代码当前在类中作为静态字符串列出： public class PageCodes { public static final String FOFP = "FOFP"; public static final String FOMS = "FOMS"; public static final String BKGD = "BKGD"; public static final String ITCO = "ITCO"; public static final String PURF = "PURF"; // etc.. } 通常在代码中，我们会看到这样的代码（第一种形式）： if (PageCode.PURF.equals(destinationPageCode) || PageCodes.ITCO.equals(destinationPageCode)) { …

11 java  design  enum