Re: Is it possible to have globally accessible classes?
james wrote:
Hi all,
I'm fairly new to java and OOP in general so i'm sure there will be a
simple answer to my question, I just can't seem to find anything on
google.
The problem is I have a class called 'Server' and a class called
'ServerConfiguration', along with several other classes. In the main
method of the Server class I create a new instance of
ServerConfiguration passing with it the url of the config file. The
problem comes when I want to use this instance of the
ServerConfiguration class in other classes. I don't want to declare
another instance in each class as loading the xml file each time could
be quite resource intensive and i don't really want to have to pass it
as a parameter when instantiating the class as they're will be alot of
classes and I can see that this method could get quite confusing.
Basically what I want to know is if there is a way I can declare the
class once and then use that instance from within the other classes.
One way is to have the ServerConfiguration class maintain
a cache of URL's and the corresponding ServerConfiguration
instances, and for Server to get a ServerConfiguration by
passing the URL to a "static factory method." A sketch:
public class ServerConfiguration {
/** Private constructor for internal use only */
private ServerConfiguration(URL url) {
// build a new ServerConfiguration
}
/** Cache of all known ServerConfigurations */
private final Map<URL,ServerConfiguration>
allConfigs = new HashMap<URL,ServerConfiguration>();
/** "Static factory method" to get the SC for a URL */
public static ServerConfiguration getInstance(URL url) {
ServerConfiguration conf = allConfigs.get(url);
if (conf == null) {
conf = new ServerConfiguraton(url);
allConfigs.put(url, conf);
}
return conf;
}
}
That is, you build the ServerConfiguration for a given URL
only once, and then re-use the same instance whenever you're
asked for a configuration with the same URL. This supposes
that the state of the SC is governed by the URL and nothing
else; if you were to build another one from the same URL five
minutes from now, you'd get "the same" SC. It also supposes
that the SC doesn't change in any important way after being
built, that Server doesn't perturb its SC in a way that would
make it unsuitable for the next requestor.
This approach can be simplified a bit if you are 100% sure
there will be only one SC in play, ever. IMHO, assumptions of
this kind, however axiomatic they may seem at first, have a way
of falling apart as time passes and features are added. Better,
I think, to allow for the possibility of multiple SC's than to
assume there will be only one (a "singleton") and later regret
having made the assumption. Think about people who wrote code
to display on "the" screen or to do things with "the" network
interface or to find out something about "the" CPU ...
--
Eric Sosman
esosman@ieee-dot-org.invalid