Talk:Enum

As you mentioned it, the decision to define a finite set of module categories was not correct, as it would have been possible to foresee the needs for custom module categories.

However, there is a one simple solution for this kind of problems. First, define a ModuleCategory interface, with some operations to get the properties of a module category. Second, define an enum called StandardModuleCategory, which implements this interface and define the standard module categories. Finally, define a class called CustomModuleCategory that also implements this interface. And use the interface everywhere in your code. You can also create an utility class called ModuleCategoryProvider with a single method named lookupByName(), or have a complete ModuleCategoryRepository.

--stephane.appercel@neuf.fr 16:05, 13 January 2011 (CET)

Simple solution except hidden API catches! Remember the enum already exists in your API, you cannot define it as StandardModuleCategory! You can't just: use the interface everywhere in your code! Your whole API is already using the old enum, you need to keep it unchanged in order to preserver BackwardCompatibility.

--JaroslavTulach 22:14, 16 January 2011 (UTC)

We ran into this same issue last year and had to replace enums by classes in some places.

However, sometimes enums make life easier. An API can be extended to support enums letting the user the freedom to use them or not. As an example here is a method I use for creating swing comboboxes. The standard version can be used with any class, but the enum version adds value in automatically determining the possible item values:

public <E extends Enum<E>> JComboBox addComboBox(
  String label,
  final Accessor<E> accessor,
  String constraints) {
    E[] values = DataUtil.enumValues(accessor.getType());
    return addComboBox(label, accessor, values, constraints);
}
 
public <E> JComboBox addComboBox(
  String label,
  final Accessor<E> accessor, 
  E[] values, 
  String constraints) {
   ...
}

--Axel 10:44, 15 January 2011 (CET)

Looks like your API also benefits from the Enum marker superclass. Otherwise you could not type the first method... --JaroslavTulach 22:14, 16 January 2011 (UTC)

A way around this is to implement an interface on your enums, and code to the interface wherever possible.

If you have code which *really* needs enums, you can use the signature <T extends Foo & Enum<T>> to require one, without specifying the exact type.

--Tim Boudreau 18:20, 23 September 2013 (CEST)

As enums can provide also mehtdos, I think it's better this way:public enum Colors { RED( #ff0000 ), BLUE( #00ff00 ), GREEN( #0000ff ); private String css; private Colors(String css) { this.css = css; } public String toCSS() { return css; }}

--Ademir 07:35, 21 October 2013 (CEST)

Do you know, who I can do that in compact fmwreaork?because BinaryFormatter doesn't exist. /// /// Implementacion de la interfaz IClonable. /// Retorna un objeto clonado. public object Clone() { MemoryStream buffer = new MemoryStream(); BinaryFormatter format = new BinaryFormatter(); format.Serialize(buffer, this); buffer.Position = 0; return format.Deserialize(buffer); }

--Ilker 07:36, 21 October 2013 (CEST)

The article rdnmies me of the following quote: The first thing they teach you in programming class is the if statement. You then spend your rest of your career trying to avoid it. In the past I have occasionally used similar tactics to those Mark eludes to:private final static Boolean WITH_CACHING = Boolean.TRUE;private final static Boolean WITHOUT_CACHING = Boolean.FALSE;This is obviously not type safe but is very explicit when reading code and means no additional commenting.I think this is equivalent to the enum suggestion ( I guess you'd have to make the Use and DontUse enum implement the same interface though for it to work?)I don't like the idea of passing a map of options because it is not type safe and is quite verbose in both the caller and callee . It's more tempting to fight it using OOAD and DDD. Strategy patterns, fine grain services etc things which will add a certain level of complexity and more classes. I abhor large classes so would rather use these.

--Jimmy 00:15, 22 October 2013 (CEST)

First, class specifier neeedd for another reasons (to access NewEnum::NE_One).The reason why your code is working with type specified but without class' keyword is that VS2010 just doesn't support this C++0x (yet)!But VS compiler already had C++ extension to specify types for enumerations similar to proposed in C++0x standard but intended for their clr (layer between C++ and C#) . I get this warning for example:C4480: nonstandard extension used: specifying underlying type for enum enum'An extension to the language under /clr was used without /clr. You can disable C4480 with the warning pragma.

--Gustavo 11:59, 23 October 2013 (CEST)