Java – Is Public Final OK in Constant Enum Fields

java

When I make enums that hold some fields, like my Settings enum, I like to make them public final to avoid lots of ( and ) keystrokes:

public enum Settings {
  SETTING_TEST("bool_setting1", false),
  USERNAME("user_name", "me")
  ;

  public final String name;
  public final Object default_val;
  Setnames(String n, Object d) {
    name = n;
    default_val = d;    
  }
}

This enum is then applied to look up (or set the default) settings in some hashmap (encapsulated in more sophistiated class). This design allows to control the setting names over the whole project (since enum names can be refactored, unlike strings).

My teacher warned me about this design though, and there are some answers suggesting that you can regret designing your project with public final without encapsulation.

I'm not only asking for rules and conventions but also your experience (the help center doesn't say anything negative about asking for opinions, so I do so). While I'd gladly even expand the question on other languages that support features in question, I'm not sure this wouldn't make the question too broad – which is why I think we should stick to Java only.

Edit:

The SE GUI asks me to explain how is my question different from the one I linked to. Other people already pointed out in comments the difference, but let's repeat it:

Most answers on the other question point out problems not applicable to enums. Often we use getXXX encapsulation to allow classes extend our class properly. But we cannot extend from enum. Generally, despite similar syntax, enums are substantially different from classes and interfaces.

Best Answer

My personal opinion is that public final is generally fine everywhere, not just on enums.

In my book, there are only two reasons for not using public final, and these are:

Allowing for future changes which might require altering the nature of the fields while maintaining binary compatibility with external code. (A getter would allow this.)
Typing 'get' and letting autocomplete show me everything that I can read from an object without having to scroll up and down in the autocomplete list to see if besides getter methods there are also any public final fields that I can read (whose names presumably do not start with get.)

As for the points made by the answer that you linked to, none of them are applicable to enums.

So, even if you don't agree that public final is generally fine everywhere, still, at least for enums, it is really-really fine.

Related Solutions

Should a String Constant Be Defined if Used Only Once?

Try this. The initial reflection is certainly expensive, but if you're going to use it many many times, which I think you will, this is most certainly a better solution what what you're proposing. I don't like using reflection, but I find myself using it when I don't like the alternative to reflection. I do think that this will save your team a lot of headache, but you must pass the name of the method (in lowercase).

In other words, rather than pass "name", you would pass "fullname" because the name of the get method is "getFullName()".

Map<String, Method> methodMapping = null;

public Object getNode(String name) {
    Map<String, Method> methods = getMethodMapping(contact.getClass());
    return methods.get(name).invoke(contact);
}

public Map<String, Method> getMethodMapping(Class<?> contact) {
    if(methodMapping == null) {
        Map<String, Method> mapping = new HashMap<String, Method>();
        Method[] methods = contact.getDeclaredMethods();
        for(Method method : methods) {
            if(method.getParameterTypes().length() == 0) {
                if(method.getName().startsWith("get")) {
                    mapping.put(method.getName().substring(3).toLower(), method);
                } else if (method.getName().startsWith("is"))) {
                    mapping.put(method.getName().substring(2).toLower(), method);
                }
            }
        }
        methodMapping = mapping;
    }
    return methodMapping;
}

If you need to access data contained within members of contact, you might consider building a wrapper class for contact which has all methods to access any information required. This would also be useful for guaranteeing that the names of the access fields will always remain the same (I.e. if wrapper class has getFullName() and you call with fullname, it will always work even if contact's getFullName() has been renamed -- it would cause compilation error before it would let you do that).

public class ContactWrapper {
    private Contact contact;

    public ContactWrapper(Contact contact) {
        this.contact = contact;
    }

    public String getFullName() {
        return contact.getFullName();
    }
    ...
}

This solution has saved me several times, namely when I wanted to have a single data representation to use in jsf datatables and when that data needed to be exported into a report using jasper (which doesn't handle complicated object accessors well in my experience).

Java Design Patterns – How to Use Decorator and Factory Together to Extend Objects

Yes, SpecialTable can be produced by the same factory (and by the same factory method) that produces Table. This not a problem, as long as SpecialTable provides at least the methods guaranteed by the Table interface (which it does).

This sort of situation makes sense when objects returned from the factory have some guaranteed behaviour/functionality (interface Table), and some optional stuff (interface SpecialTable).

So, in order to make use of the optional extra abilities/stuff available on some concrete objects returned by the factory, you have a few choices:

use polymorphism (recommended)
make use of instanceof (or similar), which can be used to check for interface compliance/exact typing (avoid this if possible!)

Using polymorphism

An example to illustrate: suppose SpecialTable has extra data and an extra widget 'blarg' which appears on the UI representing special tables. Do you really need the code which uses SpecialTable to know that it needs to add 'blarg' to the UI? Or can you just have your external code ask the thing of type Table to add its necessary UI components to some UI container? Then the calling code doesn't care what exact type the thing is -- SpecialTable deals with it, adding the 'blarg' to the container itself. This pattern can be described as the delegate pattern (also sometimes also known as strategy pattern).

Using instanceof (type checking)

Example of instanceof use:

// Table and SpecialTable are interfaces
Table table = TableFactory.instance().getDefaultTable();

if (table instanceof "SpecialTable") {
  SpecialTable specialTable = (SpecialTable)table;
  specialTable.specialMethod();
}

table.normalMethod();

Note that when you define your SpecialTable interface you can declare it as extending the Table interface and then only list the extra methods.

Your factory will be producing concrete objects of either type. So you might have a concrete class called BoringTable which implements Table, and a concrete class called ExcitingTable which implements SpecialTable.

Beware instanceof!

It's generally better to avoid things like 'instanceof' (or generally speaking, ifs of any kind which depend on what type an object is). You should favour polymorphism instead. By this I mean having multiple different classes, of a common type, enclosing different behaviour in their implementation code.

Ask yourself this: does the class using something of type Table (which might also be of type SpecialTable) need to care if it's a special table or not? Can you not hide that distinction in some sort of implementation of the SpecialTable -- have it do something different, something extra, that plain old Table does?

Best Answer

Related Solutions

Should a String Constant Be Defined if Used Only Once?

Java Design Patterns – How to Use Decorator and Factory Together to Extend Objects

Related Topic