[Program design] How to manage often used objects?

[Kai Schlamp]

Hello!

I have a question regarding general program design.
I ask myself, what's the best way to handle for example a database
connection object or general settings object, that is accessed in many
different locations in my program.
Is it best to store those in a static class to easily access them, or
is it better to pass the instance itself through the whole program?

Kai

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I have a question regarding general program design.
I ask myself, what's the best way to handle for example a database
connection object or general settings object, that is accessed in many
different locations in my program.
Is it best to store those in a static class to easily access them, or
is it better to pass the instance itself through the whole program?

Pass around or singleton depending on how much clutter needed to
pass it around.

Arne

 

[Stefan Ram]

Is it best to store those in a static class to easily access them

One can not condemn this solution, because this is just the
way Sun is doing it with »java.lang.System.out«, and I have
not heard criticism of »java.lang.System.out«.

In fact, most Java tutorials start with a simple program using
»java.lang.System.out«. I have not yet heard someone
criticising these tutorials for »teaching a bad style right
from the start«.

Another solution is a static getter, like
»java.lang.Runtime.getRuntime()«.

is it better to pass the instance itself through the whole program?

If it is an object used for debugging, than, to get the
production version without it, all interfaces would need to be
changed.

Thus, public static fields can be used, but care is needed to
tell, when to use them and when to use non-static fields or
parameters or other means instead.

 

[Lew]

One can not condemn this solution, because this is just the
way Sun is doing it with »java.lang.System.out«, and I have
not heard criticism of »java.lang.System.out«.

In fact, most Java tutorials start with a simple program using
»java.lang.System.out«. I have not yet heard someone
criticising these tutorials for »teaching a bad style right
from the start«.

Another solution is a static getter, like
»java.lang.Runtime.getRuntime()«.


If it is an object used for debugging, than, to get the
production version without it, all interfaces would need to be
changed.

Thus, public static fields can be used, but care is needed to
tell, when to use them and when to use non-static fields or
parameters or other means instead.

If something belongs to the class as a whole, make it static.

If not, make it instance.

If in doubt, usually (not always) make it instance.

 

[Mark Space]

Hello!

I have a question regarding general program design.
I ask myself, what's the best way to handle for example a database
connection object or general settings object, that is accessed in many
different locations in my program.
Is it best to store those in a static class to easily access them, or
is it better to pass the instance itself through the whole program?

Kai

Recently there's has been some trends to use design patterns such as
Inversion of Control, including Dependency Injection and Aspect Oriented
Programming. Look those up with Google, the results are interesting.

I would, without knowing anything else about your system, make a single
factory object that returns a single reference to this expensive object:

class MyFactory {
private static DBC dbc;
public DBC getDBC() {
if( dbc == null)
dbc = new DBC();
return dbc;
}
}

But don't let your lower level routines call it directly. Instead,
inject either this object (or the result of its getDBC() method) into
the lower level business object by passing the dbc as a parameter. You
can do it at object creation as part of the constructor

ShoppingCart cart = new ShoppingCart( customerName,
MyFactory.getDBC() );

or create the object, then set the dbc with a setter method.
ShoppingCart cart = new ShoppingCart();
cart.setDBC( MyFactory.getDBC() );

The thing to watch for is testing. It's hard to test when there's hard
coded references to a class like MyFactory everywhere. By setting a
parameter, you can test just by making a test DB object and passing
that. Your code will automatically be more flexible and easier to
maintain as a result.

 

[Stefan Ram]

Another means I have not considered yet, would be dynamic scoping

http://research.microsoft.com/users/drh/pubs/dynamic.pdf

It is not implemented in Java, but one could use a call

Util.get( "name" )

which would inspect the current call stack and the variables
of each method's object for the first occurence of a variable
named »name« (or »dynamic_name«, in order to make sure that
this does not coincidentally match).

 

[Kai Schlamp]

Thanks a lot for all the answers and suggestions. You helped me a lot.
I will go the singleton way together with dependency injection. That
sounds really perfect for my needs.