Talk:Enum
From APIDesign
(Difference between revisions)
Line 11: | Line 11: | ||
--stephane.appercel@neuf.fr 16:05, 13 January 2011 (CET) | --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''! Also ''use the interface everywhere in your code'' - you can't! The whole [[API]] that you have is already using using the old enum, you need to keep it unchanged in order to preserver [[BackwardCompatibility]]. | ||
+ | |||
+ | --[[User:JaroslavTulach|JaroslavTulach]] 22:14, 16 January 2011 (UTC) | ||
+ | |||
</div> | </div> | ||
== Axel said ... == | == Axel said ... == | ||
Line 38: | Line 43: | ||
--[http://www.dua3.com Axel] 10:44, 15 January 2011 (CET) | --[http://www.dua3.com 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... | ||
+ | --[[User:JaroslavTulach|JaroslavTulach]] 22:14, 16 January 2011 (UTC) | ||
+ | |||
</div> | </div> |
Revision as of 22:14, 16 January 2011
Comments on Enum <comments />
stephane.appercel@neuf.fr said ...
Axel said ...
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)
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! Also use the interface everywhere in your code - you can't! The whole API that you have is already using using the old enum, you need to keep it unchanged in order to preserver BackwardCompatibility.
--JaroslavTulach 22:14, 16 January 2011 (UTC)