1

I never see this kind of constants declaration in any Java code around me... So i'd like to know if you see any drawback of using non-static final constants.

For exemple, i've declared a Guava function as a public constant of a given MaintenanceMode instance. I think it's better because if i created a getDecoratorFunction() it would create a new function instance each time...

Or the get function could return the single instance function that is kept private in the class, but it hads useless code... When we declare constants at class level, we declare directly the constants being public, we do not put them private and provide a public getter to access them...

public class MaintenanceMode {

/**
 * Provides a function to decorate a push service with the appropriate decorator
 */
public final Function<PushService,PushService> MAINTENANCE_DECORATION_FUNCTION = new Function<PushService,PushService>() {
    @Override
    public PushService apply(PushService serviceToDecorate) {
        return new PushServiceMaintenanceDecorator(serviceToDecorate,MaintenanceMode.this);
    }
};

private final EnumMaintenanceMode maintenanceMode;
private final long milliesBetweenMaintenances;
private final Optional<ExecutorService> executorService;


public EnumMaintenanceMode getMaintenanceMode() {
    return maintenanceMode;
}

public long getMilliesBetweenMaintenances() {
    return milliesBetweenMaintenances;
}

public Optional<ExecutorService> getExecutorService() {
    return executorService;
}


private MaintenanceMode(EnumMaintenanceMode maintenanceMode, long milliesBetweenMaintenances, ExecutorService executorService) {
    Preconditions.checkArgument(maintenanceMode != null);
    Preconditions.checkArgument(milliesBetweenMaintenances >= 0);
    this.maintenanceMode = maintenanceMode;
    this.milliesBetweenMaintenances = milliesBetweenMaintenances;
    this.executorService = Optional.fromNullable(executorService);
}

}

And i can access this variable with:

  pushServiceRegistry.decoratePushServices(maintenanceMode.MAINTENANCE_DECORATION_FUNCTION);

I guess it could lead to strange behaviours if my maintenanceMode was mutable and accessed by multiple threads, but here it's not.

Do you see any drawback of using this kind of code?


Edit: I can have multiple instances of MaintenanceMode, and all instances should be able to provide a different constant function according to the MaintenanceMode state. So i can't use a static variable that would not access the MaintenanceMode state.

Sebastien Lorber
  • 89,644
  • 67
  • 288
  • 419
  • You might find it usefull/interesting to take a look at this post http://stackoverflow.com/questions/3835283/performance-differences-between-static-and-non-static-final-primitive-fields-in – Chris B Sep 03 '12 at 13:27

2 Answers2

2

The point of a getter would be dynamic dispatch. If you have no need for it, using a public final field is perfectly fine. I even routinely write bean-like objects that have no getters, just public final fields.

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
1

By making a constant non-static, you are basically saying that the constant can only be accessed when you have an instance of that class. But it is public (in the case of MAINTENANCE_DECORATION_FUNCTION) and it is part of that class so why not make it static? The constant is, after all, a constant and it does not require an instance of that class to be used elsewhere. The variable maintenanceMode is fine as it is a private constant.

Simeon Visser
  • 118,920
  • 18
  • 185
  • 180
  • Actually, i can have multiple MaintenanceMode instances, which are all supposed to provide a different constant function. This is why i'm not making the variable static because it has no meaning at the class level. – Sebastien Lorber Sep 03 '12 at 13:42