7

I've noticed some projects like to store constants in their own file, i.e constants used globally and in the main program loop might clutter the main file so perhaps they look to place them elsewhere and then reference/import file/class.

I understand that when writing an OOP class that you'd want to keep all constants at the header of the class file so they can be referenced statically as such:

myCar.setColour(Colour.RED);

Where RED is a colour constant in the Colour class.

What is good practice for having a large amount of constants, should they just be at the top of your main file or is it in any way wise to have maybe a ProgramConstants class that is purely static, public and available to read?

insidesin
  • 735
  • 2
  • 8
  • 26
  • Class level for using constants inside that class. Program level for using constants in a set of classes. – Fran Montero Jul 17 '15 at 10:31
  • What is the definition for Program level? Inside or outside the main class? – insidesin Jul 17 '15 at 10:33
  • I think the best practice is not to have large amounts of constants in the first place :) – biziclop Jul 17 '15 at 10:35
  • possible duplicate of [What is the use of interface constants?](http://stackoverflow.com/questions/2659593/what-is-the-use-of-interface-constants) – Kai Jul 17 '15 at 10:35
  • @biziclop Large number of constants is not the problem. The constants only look large when put into a single file. The JDK has way too many constants and if you count them, you could say the the number of constants are "large". (The wrapper classes alone account for 10+ constants). The problem is putting large number of constants into a single file. – Chetan Kinger Jul 17 '15 at 11:11

4 Answers4

7

What is good practice for having a large amount of constants, should they just be at the top of your main file or is it in any way wise to have maybe a ProgramConstants class

The decision about where to place constants should depend on the type of constant.

The Integer class in the JDK has a constant called MIN_VALUE that defines the minimum value of an int. The Character class defines a constant named MIN_VALUE as well which defines the minimum value of a char.

Compare the above approach with the approach of defining a global WrapperConstants class/enum with two constants namely CHAR_MIN_VALUE and INT_MIN_VALUE. You will soon be adding more constants to this file for other data types.. ( LONG_MIN_VALUE, FLOAT_MIN_VALUE and so on...)

What happens when you also want to define MAX_VALUE? See how quickly your class can explode? What about readability. Is WrapperConstants.CHAR_MIN_VALUE more readable than Character.MIN_VALUE? Not really.

Defining constants in classes they relate to is the way to go IMO. That said, not all constants belong to Java classes/interfaces/enums. Some constants (error messages for example) are better off being placed in message bundles/property files.

Chetan Kinger
  • 15,069
  • 6
  • 45
  • 82
1

I prefer putting constants into classes where they logically belongs.

Don't put not-related constants into class like ProgramConstants, because you can create a bunch of messy constants, which will become hard to maintain.

Gondy
  • 4,925
  • 4
  • 40
  • 46
  • Even if constants are related, they should not be put into a single file. The wrapper classes in Java is a good example of related constants being defined in their own class files rather than in a `WrapperConstants` file. – Chetan Kinger Jul 17 '15 at 11:09
1

No, you should not put all of your constants in the top of your main class or in their own class, they should go in whatever class they are logically associated with.

The issue is that if a programmer sees a generic place to put something, such as a constants file, then they will put all constants in here to maintain the pattern whereas they should be putting them in the correct and logical place. Having one big constants file makes it more difficult to work with constants as they are effectively uncategorised and breaks down modularity. It is your role as an architect to avoid designing a system with traps like these.

So, say for example you have system properties that are related to the running of your Java application then by all means have several of these constants in your main class. If you end up having too many in your main class then move these out in to a SystemProperties class in the same package. When a programmer needs several constants for their own use, say for colours in your example, they should create their own Colours class that goes in the package associated with that feature that contains these constants.

Mardoz
  • 1,617
  • 1
  • 13
  • 26
1

"Should all constants be defined in a single file?"

Absolutely not. In all but the smallest of programs, that would create a single point of contention/mess. Very similar to the 'global variable' anti pattern.

"Should constants be in their own files?"

Again, no. Broadly speaking, there are three types of constant and they each need to be grouped in their own slightly different way.

  1. Constants that are part of the internal implementation detail, they belong close to the implementation code using them.
  2. Public API constants. That is constants that form part of the exposed public contract of an API, they belong close to the API that is being defined.
  3. System configuration for the program. These constants belong with bootstrap code for the system.
Chris K
  • 11,622
  • 1
  • 36
  • 49