Alternative to using enum

Question

The project I'm working on has a code dependency on a TeamNames enum. The problem with this is that the project needs to be recompiled and redeployed on any addition/deletion in TeamNames. How can I remove this dependency?

I have come up with 2 possible solutions:

1. Accepting each and every TeamName as a String field. The issue with this is possible garbage values being entered by the user.
2. Storing TeamNames in a DB and validating when the user enters the name. Creating a single-column table in a DB just for team names would be overkill IMO.

What alternatives could I look into, to find a better approach to solving this?

Answer 1

Creating a single-column table in a DB just for team names would be overkill IMO.

Create a proper Teams table then. With a key and Name and maybe some other properties that a team may have. This can be shown to the user as a select box. The user will see the name, the application will use the key for all its operations.

Answer 2

The project I'm working on has a code dependency on a TeamNames enum.

So you have data that relates to each Team.

That says to me that Team is a data Entity that you care about and, since a Team can probably exist in its own right, that means it should have its own table.

The problem with this is that the project needs to be recompiled and redeployed on any addition/deletion in TeamNames.

Adding and removing rows from a table is far easier than hacking about, changing [lots of] code that is dependent on an Enum. Also, you can almost guarantee that, someday, someone will want to add a Team whose name contains characters that are illegal in a Java identifier. Database columns are far more "forgiving".

Creating a single-column table in a DB just for team names would be overkill IMO.

I would wager that, in a fairly short period of time, you'll find other data attributes that pertain directly to each Team and you'll add them. Even if you don't, having these values in a table is still the best approach.

Answer 3

From your post it is not clear whether team name is the name of a team member or of a team role.

If team name refers to a team role which might change on the request of the user, but not too frequently you could use an array of strings and store the array in a property. The next step would be to decide how to maintain the property file. You can change it manually or add an update function.

If instead team name refers to names of team members that might change more frequently the DB solution even for a few data would be more flexible, but it will require extra work to add all the update functionalities.

Answer 4

Without doubt an enum is a closed value domain, and also a bottle neck on maintenance, like rebuilds and vcs merge conflicts and so on.

1. An interface for team name typed constants. For different groups could define a child interface (Responsibility principle). Packing this value domain in a type is good practice. So there could be a class Team (?).

2. Database. Hmm, does a team not more or less corresponds to a group, comparable with a authentication user, a Principal. Maybe you should look for those kind of solutions. That is if the usage involves roles, rights. Some solutions are very basic and open ended. So not too much effort. The user/group realm could for instance be XML based.

It is a matter of the intended scope. (1) is simpler - no extra knowledge acquisition, (2) more ambitious - one could start with annotations etcetera.