This is a general OOP question, as I didn't know if this is an 'accepted' practice in programming!

I have some classes in my application that only ever get instantiated once - for example, a class that defines application settings and properties. However, when I want to reference this class instance from another class, I'm kinda stumped because I don't have a visible reference to my class instance.

Sure, I could pass the class instance reference into the functions that need it, but that seems ugly.

Instead, I've added a static reference to the class instance, and can therefore refer to that instance from any other class.

Example:

[source lang="java"]public class Settings
{
// static reference to a settings object
public static Settings ref;

public Settings()
{
// apply a self-reference
settings = self;
}

private void doSomething()
{
...
}
}[/source]

So, from another class file entirely, I can refer to my single Settings class instance by using the in-built static reference, giving me access to its private methods:

[source lang="java"]Settings.ref.doSomething();[/source]

Is this an acceptible method of doing this? Or is this type of self-referencing frowned upon? Should I just make all required 'public' members and methods in the class static instead?

[source lang="java"]public class Settings
{
public Settings()
{
// do nothing
}

public static void doSomething()
{
...
}
}[/source]

I'm looking forward to some insight on this!

Thanks all!

This has the problem of "lack of imagination". You might not have a reason to have more than one Settings object right now, but you might in the future. For instance, you may want to create a test where you check that two objects configured with different settings have the same behavior (say, one of the settings uses a naive algorithm and the other uses a fancy algorithm that should give the same results). If you hard-code the single instance in your code, you are closing the door to this possibility in the future.

Of course, using a global instance of the class, or making all the members static, all have the same problem.


The code I work with most days has a huge class of which only one instance can exist, and we have been living with it for years, although it's a mess and we have tons of examples of interesting things we could do if we could create more than one copy. The rest of the code (I am talking hundreds of thousands of lines of code) use this class all over the place.

Passing your Settings object around is not ugly: It's making a dependency explicit.

Thanks, I can see your point about it potentially closing the door to using further instances of the class for other reasons.

It might help to give some background on the class. It's a Canvas for a drawing / modelling application, so I know for a certainty that there can only ever be one instance of the class active at any time (this isn't a multiple-workspace type of project). A workspace can only have one canvas.

Perhaps I need to think about reorganising the communication of data between the classes outside of the workspace so that rather than relying on a call directly to a static method inside of the Canvas object, I can pass a reference to the (only) instance of the Canvas to the required classes as an argument.

It'll just mean a bunch of refactoring - but eh, if we had a few bucks everytime we did that...

I really don't like singletons, but there's a pattern I developed for a large scale project to overcome the lack of testabillty and the implementation coupling that the singletons usage brings :

[source lang="java"]public abstract class Settings {
private static final SingletonHolder <Settings> HOLDER = new SingletonHolder<Settings>("implementation.property");
public static final Settings getInstance() {
return HOLDER.getInstance();
}
public abstract void foo();
}

public class DefaultSettings extends Settings {
public void foo() {
// Do your thing
}
}

public class SingletonHolder <Type> {
private final <Type> instance;
public SingletonHolder(String property) {
this.instance = Class.forName(System.getProperty(property)).newInstance();
}
public Type getInstance() {
return instance;
}
}
[/source]

For the sake of brevity, I didn't write the exception handling code, and the SingletonHolder should be aware of changings on the value of the system property used to fetch the implementation's class name.