When to use enumerations?

Question

I have this example (in Java) where there are models, each with the same set of types. I defined the types as enumerations. When I went to present this program to the advisor (it's a project), he stated it wasn't wise to use enumerations as it makes the program inflexible for changes because enumerations are not extendable. So if I want to add another type at some point, I cannot do this without recompiling. Is there ever a situation where you'd prefer enumeration over creating objects instead? It seems to me that if you can choose between a flexible class with objects and a non flexible class with enums, you might as well use objects every time, even when you're '99%' sure the types will never change.

Answer 1

Using enums improves static/compile time analysis. You can only use the enums you specified.

Whether this is good or not depends on whether the library is for internal or external consumption.

For internal consumption, re-compiling is not an issue. You have access to the source you can add another value whenever you need. Part of the value of an enum is the compiler time checking it gives you so re-compiling is a good thing in this case.

For external consumption, you have to be much more careful. You have to be more confident there is no supported reason to add another value. (There might be reasons to extend the values but if these are not supported, they can't do it anyway) A user of your library will not want to be/possibly won't be able to recompile your library just to add some functionality.

What I do is try to get the best of both worlds.

• I define and use an interface
• I have implementations which are enums

This allows you to use enums, but you allow a user of the library to define their own implementations which could be their own enums, or dynamically created instances.

---

Here is an example of an enum for an interface which could be extended but AFAIK, no one has. StopCharTesters

public enum StopCharTesters implements StopCharTester {
    COMMA_STOP {
        @Override
        public boolean isStopChar(int ch) {
            return ch < ' ' || ch == ',';
        }
    }, CONTROL_STOP {
        @Override
        public boolean isStopChar(int ch) {
            return ch < ' ';
        }
    },
    SPACE_STOP {
        @Override
        public boolean isStopChar(int ch) {
            return Character.isWhitespace(ch) || ch == 0;
        }
    },
    XML_TEXT {
        @Override
        public boolean isStopChar(int ch) {
            return ch == '"' || ch == '<' || ch == '>' || ch == 0;
        }
    },
    FIX_TEXT {
        @Override
        public boolean isStopChar(int ch) {
            return ch <= 1;
        }
    };

etc.

Answer 2

You'd use enumerations every time that there is a finite amount of possible states for an object. Every time, regardless of what your supervisor is saying. And yeah, take a look at this:

Enumerations: Why? When?

Answer 3

1. You prefer enumeration when its members can never be changed. For example if you are developing chess program you can be absolutely sure that the list of chess pieces will never be changed.
2. when changing the members of enum requires other changes in code. For example if your enum presents encryption algorithm you cannot just add new algorithm. You have to implement it. This mean that your program has to be re-compiled anyway. Please note that this rule is not absolute: you can create program that discovers available implementation of specific interface dynamically.