TL; DR

Assuming an enumeration used to map domains defined in a system's business rules, it does not need to be constant, but must respect the business rules and, if necessary, change along with them.

Because we use enumeration

The enumeration is mainly used for two reasons:

1. make life easier for the developer who does not need to consult the system manual at all times to remember which values a field can assume and the meaning of these values.
2. enforce compile-time constants validity. This avoids literals scattered throughout the code that can inevitably lag behind the actual values used in the system.

Should we change an enumeration?

When we use enumerations to map database values, we must ensure that they keep track of the values that are in the database.

These values are usually from a domain defined in the system documentation. The care not to change them will be the analyst and not the developer.

If at a certain time the responsible analyst decides that the code 7 will no longer be the equivalent of Parcela Paga and should now be Parcela em Atraso, he must assume the consequences of the decision:

1. in the database (update in tables, procedures, triggers, views, queries)
2. change in Enum s and code refactoring impacted
3. updating descriptions and fields on screens
4. Etc., etc., etc.

The advantage of using an enumeration provided by the programming language is that if you change the description of it, you can easily find the affected points because they will no longer compile.

In addition, several IDEs allow you to find all the points where a certain value is used not only by the name of the same, but by analyzing the semantics of the code.

Techniques for dealing with enumeration augmentation

Use polymorphism

Enumerations replace very well simple constants. However, if the developer stops using features that the language offers and uses Enum s as if they were constants, stuffing the code with IF s, the growth of the value set will be more error prone.

In Java, for example, instead of simply grouping IF s like this:

if (TipoFuncionario.Celetista == functionario.getTipo()) {
  //validar celetista
} else if (TipoFuncionario.QuadroPermanente == functionario.getTipo()) {
  //validar quadro permanente
} else ....

We could append add a parameter to the Enum constructor to force the developer to declare a validator for each added value.

public enum TipoFuncionario {

    Celetista(new CeletistaValidator()), 
    QuadroPermanente(new QuadroPermanenteValidator()), 
    Surfista(new SurfistaValidator());

    private FuncionarioValidator validator;

    private TipoFuncionario(FuncionarioValidator validator) {
        this.validator = validator;
    }

    public FuncionarioValidator getValidator() {
        return validator;
    }

}

So the whole place could just call the validation like this:

funcionario.getTipo().getValidator().validate(funcionario);

Note that to add new values it is not necessary to change the existing code.

^{Note: This example was extracted from another answer of mine here in the SO.}

Set individual values for each constant

The Java language has a serious problem with the Enum s: it is not possible to set a value for each constant as quoted in the question.

You can even get an integer based on the order of the constant, but relying on the declaration order of the constants doesn't seem consistent at all to me.

So instead of doing something like:

public enum MeuEnum { valor1, valor2, valor3}

We should always associate the value with a constant to map values of a domain:

public enum MeuEnum {
    valor1("V1"), valor2("V2"), valor3("V3");

    String id;
    private MeuEnum(String id) { 
        this.id = id; 
    }

    public String getId() {
        return id;
    }
}

In the example above, we can map values of text or number domains, without worrying about the order or the name used for each element of Enum.

Cases where we should not use enumerations

There is a rule ( rule of thumb ) something like this:

If it changes, parametrize!

If a domain is constantly changing, an enumeration may not be the most appropriate answer.

It would probably be better to create a database and allow the configuration of some characteristics of each element.

This is much better than refactoring and recompiling the code often.

Final considerations

Change is inevitable.

If it is very common, a more generic solution than Enum s may be recommended.

Otherwise, the ideal is to use an OO approach according to the language used to reinforce the due treatment of each element in build time.

And finally, we must keep in mind that the change of a Enum is usually the result of change in the business, which must be properly analyzed to cause minimal impact on the system.

Some analysts have the custom of never delete an element from a domain, just deprecate it and add a new option to be used in new versions of the system. I think it is not always possible, but it is a good approach to be able to maintain historical data.

What problems could this [modifying an enumeration] cause?

Depends on how this enumeration is modified. If the object uses enumeration to persist data in the database, for example, adding new elements may result in a problem if the integer related to the value is either not specified, or is modified.

If not specified, the programmer can add new values to the middle of the sequence. From your example:

enum Acoes { Falar, Cantar, Gritar }

Thus specifying, the language takes the default value for Falar as 0, Cantar as 1, and Gritar as 2. Modifying as follows:

enum Acoes { Falar, Cantar, Gritar, Sussurrar, Calar }

Does not result in problems, since the elements have been placed at the end. Already this modification:

enum Acoes { Falar, Cantar, Calar, Sussurrar, Gritar }

Makes Gritar have a new implicit value (4). When you bring the database data, records that were previously saved as Gritar will appear as Calar.

If it's not a good idea, what solution should be adopted when it is known that enumeration can "grow"?

As said before, of two, one:

• specify the values of each enumeration element;
• do not change the initial order, adding new elements only at the end of the statement.

And what to do if an enumeration has been created, used extensively in your application, and now it has been found that new members are needed?

The previous topic already answers it.

If I have a range of values that will be obtained at runtime (coming from an XML or DB, for example), in languages that is possible, would it be appropriate/would it make any sense to create an enumeration dynamically (with reflection, for example)?

No. This is to distort the meaning of the enumeration, which exists to work with a set of fixed and limited values.

It is even possible to do this, but it would compromise the security of the data, and consequently the set everything up.

Does it make a difference if the enumeration is used to treat a set of flags? To be used with or

In compiled and executed code, everything turns int or float. Then no.

Modern languages often have an enumeration type that is usually a range of related constants.

Translating: C-derived programming languages usually have an enumeration type that is usually a range of related constants.

The most noticeable difference appears in ML-inspired functional languages such as Haskell. In them algebraic types (ADTs) can be used to describe enums constants:

data Color = Red | Green | Blue

And can also be used to describe data structures with more than one"case". In an analogy to C it is as if it were a union with a built-in enum used as a "tag".

-- Uma árvore é ou uma folha contendo um inteiro
-- ou um nó interno que contem uma chave inteira e duas sub-árvores.
data Tree = Leaf Int | Node Int Tree Tree

To use ADTs, these languages provide Pattern matching, which is like a switch that ensures that the branches are executed correctly (cannot extract the "right child" from within the "leaf"branch)

-- Função que soma os elementos da árvore
sumTree tree =
    case tree of
        Leaf x = x
        Node x t1 t2 = x + (sumTree t1) + (sumTree t2)

Back to your questions:

Besides this it should be obvious that no programmer will change the values of its members from one version to another.

The main feature of an enum is that the values are different and that we can make a switch about them. If we only worry about it the value the compiler uses internally makes no difference.

If it is not a good idea, what solution should be adopted when it is known that the enumeration can "grow up"?

Consider a data type with multiple cases (e.g. sheet vs tree node) over which we want to perform various functions (e.g. insert and search in the tree).

If we use an implementation with ADTs / enums it is easy to introduce new functions without messing with the previous ones but to introduce a new case to the type we need to mess with all the existing implementations to treat the new case in switch.

On the other hand, if we use a object-oriented implementation it is easy to add a new case to the type (create a new class by implementing all existing methods) but it is difficult to create a new function (you need to add the method implementation to all existing classes).

In English this dichotomy is usually known as"expression problem".

And what to do if an enumeration has been created, used extensively in your application and now it has been found that new members are necessary?

The simplest solution is to simply add a new member to the enum and let the compiler warn you at all switch that you forget to treat one of the cases. In C and languages with a similar switch it is sometimes difficult to make the compiler generate these messages consistently, especially if the enum is converted to int in the middle of the process, but in Haskell this is certainly extremely natural to do.

If I have a range of values that will be obtained at runtime (coming from an XML or DB, for example), in languages that is possible, would it be appropriate/would it make any sense to create an enumeration dynamically (with reflection, for example)?

I find it more sensible to separate the internal values used by the compiler from the values of the external representation. I would create a small function to convert numbers in XML to elements in my enum.

Makes a difference if the enumeration is used for treat a set of flags? To be used with the or binary.

In this case you will never make a switch or if-else over an enumeration value. For me this is a real enum and it's just a coincidence that in C you can use enums to define these flags.