Is it good to Sharing constant strings in Java across many classes?

Question

I'd like to have Java constant strings at one place and use them across whole project?I am confusing Is it a good practice for better readability or not?

Answer 1

If you think that your Strings are going to be referenced in many flows, then it is good to use. Moreover, it is a widely accepted practice as well.

Answer 2

It is good to create Interface & declare your all constant in it. E.G

public interface ICommonConstants {
    public static final String ENCODING_TYPE_UTF8="UTF-8";
} 

Implement this interface in your all class where you like to use constants.You can use by calling

ICommonConstants.ENCODING_TYPE_UTF8

Answer 3

Code duplication is a code smell and if you wouldn't use readily available constants you need to re-declare the String over and over again for each class using it, which is bad.

This leads to less maintainable code, because when the duplicated String needs to change and you forget to update it in one of the classes, the code breaks.

It's common practice to set up a class holding reusable constants:

public final class MyDefs {
    public static final String A = "a";
    public static final String B = "b";

    private MyDefs() {
        // Utility class, don't initialize.
    }
}

Answer 4

Simple: when multiple classes need the same information, then that information should have a single "root".

So yes: it is absolutely good practice to avoid re-declaring the same value in different places. Having a "global" constant simply helps with avoiding code duplication - thus preventing errors later on, when you might have to change such values.

Answer 5

I would recommend an Enum, or you could just have sort of like a utility class with just static final strings. All depends on what you want do i guess, i don't see anything bad. if the class is going to be shared by many classes, that's fine.

Answer 6

One single class with (unrelated) constants has problems. It is a bottleneck: if in a team a constant is added at the bottom, someone else adding a constant will receive a VCS conflict. Enforce the declarations to be sorted alphabetically. It also ties this package together in other forms. Still many unneeded recompilations would be needed (see also the remark at the end).

In java 9 with modules, you would in every using module need to require the constants classes module, probably causing an unnecessary module graph.

Then there are constants which need not be named and still are not "magic". In annotations as arguments. An annotation scanning can gather those values if you need uniqueness or such.

And finally there are shared constants. Near the used constructs is still my favourite.

Also the constants class pattern tends to be used often with String constants. That reeks of code smell, as it is a kind of burocracy where one should use automatic mechanisms, OO, fixed conventions, declarative data.

For database tables and columns there exist better mechanisms.

Classes with constants (still) have the technical compilation problem that in java the constant is incorporated in the .class file itself, and the import disappears. Hence changing the original constant will not notify the compiler to recompile the "using" class. One needs a full clean build after recompiling a constants class.