1

I've created an interface with the following code

final static char RIVER = '~';
final static char PATH = 'Y';

The list will increase (not hundres or even tens but maybe at most 15 symbols)

Originally I was just coding the values directly into the object but I started wondering why I couldn't just create a single file with the global constansts (for the symbols on the map and only the symbols) for easy access.

I'm aware that per OO logic, encapsulation is how we should program. At the same time, final static variables exist so surely they do have a purpose. My question then is there a reason for me to avoid using the global constants and go back to putting each symbol with each object? Does global constants have a role to play within OO programming at all or is it purely for Procedural Programming?

This is a project that only I will ever work on however I am using as a testbed to improve my standards and as such I would like to use the best method possible (in terms of standard).

Omar Hrynkiewicz
  • 502
  • 1
  • 8
  • 21
ryan651
  • 121
  • 1
  • 1
  • 3
  • final variables are read-only variables. They are quite useful - e.g. you can access a final variable inside an inner/anonymous block of code. if you are planning to extend that list of constants consider using an enum or a static class. – Ivo Feb 19 '15 at 12:10

5 Answers5

2

Defining global constants in an interface is an anti-pattern. Either use classes to define constants and then use static imports. Or simply use enums, which gives more flexibility.

Juned Ahsan
  • 67,789
  • 12
  • 98
  • 136
2

Defining global (public static) constants is okay. It helps to keep you code clear and maintainable, by giving certain values meaningful names.

What you should not do, is define global constants in an interface and then add an implements-clause to each class that uses these constants. The reason for this, that you pollute the public signature of your class in this way. Instead, alsways refer to the constants by their full name (e.g. SomeClass.SOME_CONSTANT) or statically import them (import SomeClass.SOME_CONSTANT).

I would not define all global constants in one single file however, but define each of them in the class or interface that makes the most sense, for example because they define methods that return these constants or where the constants are typical arguments.

Hoopje
  • 12,677
  • 8
  • 34
  • 50
2

There are several benefits in use the constants, these are some of them:

  • Readability: If you hard code the number, when you or some other programmer have to use the code, they have to know what the value means. If a constant is used, a meaningful name is provided.
  • Reusability: If the same constant needs to be used in several place, when a modification is needed, you only have to change the value in one place instead of all the places where the constant is used.
  • Maintainability: If you have your constants in a single place instead of multiple places in the code, it is easier to modify.

It is considered a bad practice to use interfaces to hold the constants, use classes instead. If the constants are related with the class, you can define the constants within the class. If they are general purpose constants and used in several classes, you can create an utility class to hold all the constants.

public class MyUtilityClass {
    public static final int MY_INT_CONSTANT = 1234;
    public static final String MY_STRING_CONSTANT = "example";
    ...

    /* Create a private constructor to avoid creation of instances of this class */
    private MyUtilityClass() {
    }
}
David SN
  • 3,389
  • 1
  • 17
  • 21
0

Global constants are absolutely fine.

That having been said, do not even try programming without the maximum number* of compiler warnings enabled. If you had enough warnings enabled, your compiler would be telling you that fields in interfaces do not need to be declared final and they do not need to be declared static.

(* warnings that make sense. Every compiler has its own set of warnings that are rather nonsensical and best disabled, but these are generally few.)

Mike Nakis
  • 56,297
  • 11
  • 110
  • 142
0

Encapsulation is the mechanism which protects you from changes - for example, changing the implementation of a class, will not affect the rest of your code as long as the interface (the public or protected methods) does not change.

So you can apply this reasoning to your case. Will future changes of these constants affect the rest of the code? If not, then putting all those constants as final static instances in a single class is fine. But think of this. What if you want to change how you represent your map? (from the names of the variables I assume you're using them to represent a map) Maybe you want to use special objects which also have their own behaviour, not just how to represent them on the map. Then maybe you'll want to abstract those in new classes, and not use constants anymore. And this will affect all the code where you reference these constants - probably lots of classes.

Of course, you can start with this simple representation, and if at a later point you find it's not working anymore, then you can switch. This is what I would do. I don't think it's wrong.

Andrei Vajna II
  • 4,642
  • 5
  • 35
  • 38