views:

44

answers:

3

I am working with a Class that contains constants or parameter values that all classes can reference for example;


public class Parameters {
   public static final String JUMP_TO_VALUE = "Parameters.JUMP_TO_VALUE";
   public static final String EXCEPTION_ID  = "Parameters.EXCEPTION_ID";
}

Some of the foundation classes in my application will use the parameter values in the Parameters class like so:


   mapOfValues.put( Parameters.JUMP_TO_VALUE, "some_value")

This is simple enough I have some basic values in Parameters that most of my base classes will use them. There will be many situations where I will need to add addition parameters to the Parameters class, but I don't want to over populate or pollute the Parameters class ever time a new parameter is identified. I would rather create some subclass of Parameters like:


  public class NetworkParameters extends Parameters {
      public static final String HOST_NAME = "NetworkParameters.HOST_NAME";
      public static final String POST_NUM  = "NetworkParameters.PORT_NUM";
 }

Some of my specific classes will use the values that are contained in this class versus putting them in the Parameters class.

These specific classes that need HOST_NAME for example I don't want them to reference the NetworkParameters class but rather the Parameters class.

I am sure people have done this before but I am looking for advice on how best to implement this design.

+3  A: 

It is simply not possible, in the exact way you describe it.

When you reference static objects, you refer to the class that those objects are declared in. Quite simply, if you declare a constant in the NetworkParameters class, it does not exist in the Parameters class and is not accessible as such.

Separating vast numbers of parameters into different containing classes (which don't need to be subtypes of each other as this achieves nothing) is quite good practice and often used. Why do you have such an aversion to just using NetworkParameters.POST_NUM, as this is the name of the parameter and sounds completely sensible to me?

One thing that may help you (depending on your own tastes) is to use Java 5's static import feature. If, at the top of a class file, you declare

import static the.package.name.Parameters.*;
import static other.package.NetworkParameters.*;

then you will be able to use all of the constant names from both classes without any prefix at all. This is often quite nice when it's obvious what comes from where - but it can become a nightmare if you're statically importing from a few classes, especially if you don't have an IDE to work out the reference for you.

But again - why do you want to reference them as Parameters.FOO, but want them to live in a separate class? Either approach (everything in one file, different constants in different files) is good and fine if you do it completely, but you can't magically change the laws of Java references because you don't like the look of them. :-)

Andrzej Doyle
+1  A: 

I don't think you would be overdoing it by putting a lot of constants in a single file. Just keep it well organized with good formatting and documentation. I dont think subclassing is want here. A subclass implies a certain relationship among objects. First off, you aren't really creating an object, so creating a subclass does not really fit the model here. Also, using a subclass here may just complicate things. For example, you will have to import multiple java files if you want to use several types of constants in another class.

darren
A: 

Are you sure you want to be embedding these values in your code?

They sound to me like the kind of data you want to place in a configuration file, so they can be change easily without the code needing to be recompiled. A simple hash of name-value pairs from a configuration file, wrapped to be accessible in the way you need them to, might be a more flexible approach to the same problem.

glenatron
I agree with you that the network parameters such as port number should be configurable. But even with a config file, you still really ought to have a constant string referring to the property key, and then we're back to the original question of whether `PORT_NUM_KEY` should live in `Parameters` or `NetworkParameters`.
Andrzej Doyle