Question

First of all I should probably say that the term ‘constant object’ is probably not quite right and might already mean something completely different from what I am thinking of, but it is the best term I can think of to describe what I am talking about.

So basically I am designing an application and I have come across something that seems like there is probably an existing design pattern for but I don’t know what it is or what to search for, so I am going to describe what it is I am trying to do and I am looking for suggestions as to the best way to implement it.

Lets say you have a class:

public class MyClass {
    private String name;
    private String description;
    private int value;

    public MyClass(String name, String description, int value) {
        this.name = name;
        this.description = description;
        this.value = value;
    }

    // And I guess some getters and setters here.
}

Now lets say that you know in advance that there will only ever be say 3 instances of this class, and the data is also known in advance (or at least will be read from a file at runtime, and the exact filename is known in advance). Basically what I am getting at is that the data is not going to be changed during runtime (once it has been set).

At first I thought that I should declare some static constants somewhere, e.g.

public static final String INSTANCE_1_DATA_FILE = "path/to/instance1/file";
public static final String INSTANCE_2_DATA_FILE = "path/to/instance2/file";
public static final String INSTANCE_3_DATA_FILE = "path/to/instance3/file";
public static final MyClass INSTANCE_1 = new MyClass(getNameFromFile(INSTANCE_1_DATA_FILE), getDescriptionFromFile(INSTANCE_1_DATA_FILE), getValueFromFile(INSTANCE_1_DATA_FILE));
public static final MyClass INSTANCE_2 = new MyClass(getNameFromFile(INSTANCE_2_DATA_FILE), getDescriptionFromFile(INSTANCE_2_DATA_FILE), getValueFromFile(INSTANCE_2_DATA_FILE));
public static final MyClass INSTANCE_3 = new MyClass(getNameFromFile(INSTANCE_3_DATA_FILE), getDescriptionFromFile(INSTANCE_3_DATA_FILE), getValueFromFile(INSTANCE_3_DATA_FILE));

Obvisouly now, whenever I want to use one of the 3 instances I can just refer directly to the constants.

But I started thinking that there might be a cleaner way to handle this and the next thing I thought about was doing something like:

public MyClassInstance1 extends MyClass {
    private static final String FILE_NAME = "path/to/instance1/file";

    public String getName() {
        if (name == null) {
            name = getNameFromFile(FILE_NAME);
        }
        return name;
    }

    // etc.

}

Now whenever I want to use the instances of MyClass I can just use the one I want e.g.

private MyClass myInstance = new MyClassInstance2();

Or probably even better would be to make them singletons and just do:

private MyClass myInstance = MyClassInstance3.getInstance();

But I can’t help but think that this is also not the right way to handle this situation. Am I overthinking the problem? Should I just have a switch statement somewhere e.g.

public class MyClass {
    public enum Instance { ONE, TWO, THREE }

    public static String getName(Instance instance) {
        switch(instance) {
        case ONE:
            return getNameFromFile(INSTANCE_1_DATA_FILE);
            break;
        case TWO:
            etc.
        }
    }
}

Can anyone tell me the best way to implement this? Note that I have written the sample code in Java because that is my strongest language, but I will probably be implementing the application in C++, so at the moment I am more looking for language independent design patterns (or just for someone to tell me to go with one of the simple solutions I have already mentioned).

Answer 1

If you want the values to be constant, then you will not need setters, otherwise code can simply change the values in your constants, making them not very constant. In C++, you can just declare the instances const, although I’d still get rid of the setters, since someone could always cast away the const.

The pattern looks ok, although the fact that you are creating a new instance each time one is requested, is not usual for constants.

In java, you can create enums that are “smart” e.g.

public enum MyClass {
    ONE(INSTANCE_1_DATA_FILE),
    TWO(INSTANCE_2_DATA_FILE),
    //etc...

    private MyClass(String dataFile)
    {
       this(getNameFromDataFile(dataFile), other values...)
    }

    private MyClass(String name, String data, etc...)
    {
       this.name = name;
       // etc..
    }

    public String getName()
    {
        return name;
    }
}

In C++, you would create your MyClass, with a private constructor that takes the filename and whatever else it needs to initialize, and create static const members in MyClass for each instance, with the values assigned a new instance of MyClass created using the private constructor.

EDIT: But now I see the scenario I don’t think this is a good idea having static values. If the types of ActivityLevel are fundamental to your application, then you can enumerate the different type of activity level as constants, e.g. a java or string enum, but they are just placeholders. The actual ActivityDescription instances should come from a data access layer or provider of some kind.

e.g.

enum ActivityLevel { LOW, MED, HIGH  }

class ActivityDescription
{
    String name;
    String otherDetails;
    String description; // etc..
    // perhaps also
    // ActivityLevel activityLevel;

    // constructor and getters
    // this is an immutable value object
}

interface ActivityDescriptionProvider
{
    ActivityDescription getDescription(ActivityLevel activityLevel);
}

You can implement the provider using statics if you want, or an enum of ActivityDescription instnaces, or better still a Map of ActivityLevel to ActivityDescription that you load from a file, fetch from spring config etc. The main point is that using an interface to fetch the actual description for a given ActivityLevel decouples your application code from the mechanics of how those descriptions are produced in the system. It also makes it possible to mock the implementation of the interface when testing the UI. You can stress the UI with a mock implementation in ways that is not possible with a fixed static data set.