What is the best Java programming practice: building enumerations and enum constructors or subclasses?

Question

Given a finite number of elements that differ in nature, is it better to represent them with complex enum enums and constructors, or subclass them? Or is there a better approach?

To give you some context, in my small RPG program (which, ironically, should be simple), the character has different items in his inventory. Elements vary depending on their type and use and effect.

For example, one inventory item is a spell scroll called Gremlin, which adjusts the Utility attribute. Another item may be a sword called Mort, which is used in battle and deals damage.

In my RPG code, I now tried two ways to represent inventory items. One of the methods was a subclass (for example, InventoryItem → Spell → AdjustingAttributes; InventoryItem → Weapon → Sword) and, if necessary, instantiated each subclass and assigned values ​​such as the Gremlin and Mort names.

Another way was to add enumerations and enumeration constructors. For example, I created enumerations for itemCategory and itemSpellTypes and itemWeaponTypes, and the InventoryItem enumeration was as follows:

public enum InventoryItem { GREMLIN(itemType.SPELL, itemSpellTypes.ATTRIBUTE, Attribute.UTILITY), MORT(itemType.WEAPON, itemWeaponTypes.SWORD, 30); InventoryItem(itemType typeOfItem, itemSpellTypes spellType, Attribute attAdjusted) { // snip, enum logic here } InventoryItem(itemType typeOfItem, itemWeaponTypes weaponType, int dmg) { // snip, enum logic here } // and so on, for all the permutations of items. } 

Is there a better Java programming practice than these two approaches? Or, if this is the only way, which of the two is better? Thanks in advance for your suggestions.

Answer 1

In the context that you are describing, I would consider using class hierarchies as opposed to enumeration definitions and add interfaces to this hierarchy; eg.

 /** * Root of class hierarchy. */ public interface InventoryItem { } /** * Additional "parallel" interface implemented by some (but not all) * InventoryItems and other non-inventory items. */ public interface Usable { void use(); } /** * A Spell is in InventoryItem and is also Usable. */ public abstract class Spell implements InventoryItem, Usable { } public class Gremlin extends Spell { } /** * A Door is *not* an InventoryItem but can be used. */ public class Door implements Usable { } 

The main advantage of this approach is that it allows you to process this object in different contexts (like InventoryItem or Usable s list). Another reason I should shy away from enumerations is because you are likely defining the behavior of your elements (e.g. spell.cast(Person) ), and this is not very suitable for IMHO enums.

Answer 2

Enumerations are good if only static data and very minimal logical data are stored (preferably no logic at all). If your objects are designed for different behaviors depending on their type, it is usually recommended to implement them as subclasses.

As already mentioned, you are likely to add attributes to your objects, and these attributes will not make sense for all kinds. For example. the color attribute makes sense for a weapon, but not for a spell. In this case, the weapon and spell should not be on the same listing.

Answer 3

If you want to add new attributes to elements, they are easier to implement as subclasses. Thus, if a group of elements receives a new attribute, it will apply to all subclasses.

For example, if all Weapon types get a certain weight assigned to it, you simply add this attribute to this class. This attribute will then propagate to subclasses.

As for other things that are more static in nature and therefore can be directly assigned to types, enums are good. I think it’s free here, so I believe that Weapon can assign DamageType :

 public abstract class Weapon { public enum DamageType { CUT, SMASH, PIERCE; } private DamageType damageType;