Centralizing instantiation?

[Rhino]

This is probably going to sound awkward due to my lack of vocabulary so
please forgive me....

I have a project that has 21 classes in it that do various things to do
with generating my resume. (It generates the resume in a variety of
formats like HTML, PDF, Word, etc. etc.) There is basically what I would
have called a "mainline" in my COBOL days - I suppose we might call it a
driver these days? - that kicks everything off.

Now, a few of the classes need database access - for example, I store
information about references there - and several of the classes have the
potential of generating log messages.

I'm trying to figure out when I should initialize the logging and
database connection.

I'm leaning toward getting my database connection in the constructor of
the "mainline" and then passing that connection to each of the classes
that needs it as it is invoked in the mainline. I'm also leaning toward
getting my logger during the constructor of the mainline and, again,
passing it to each of the classes kicked off by the mainline.

This ensures that both the connection and logger are available to any
class that needs it. I'm also thinking that if creating the logger or
getting the database connection is a problem, I should probably find out
right at the start and probably abort the whole program if either one has
a problem. I'm inclined to think that if I'm unable to generate log
messages when I want to write them, that I shouldn't even get started.
The database connection is a little less categorical; if it is not
available, I could conceivably generate the resumes and simply display a
message to say that the references are not currently available so try
again later.

On the other hand, there are some classes that won't ever need to log -
little convenience classes that don't have any reason to throw exceptions
- and some of the work could be done even without the database connection
being there. Also, an argument might be made to the effect that the
classes that need database access (or even the logger) could simply
create their own _when needed_. That would also simplify the code
somewhat; if I do create the logger and database connection right at the
start and pass them to each and every class, then I add two extra
parameters to each constructor making more clutter than may be viewed as
strictly necessary.

What do you folks do in comparable situations?

I have a feeling I'm thinking of this too much like a COBOL programmer
and not enough like an OO/Java programmer.....

 

[Arne Vajhøj]

This is probably going to sound awkward due to my lack of vocabulary so
please forgive me....

I have a project that has 21 classes in it that do various things to do
with generating my resume. (It generates the resume in a variety of
formats like HTML, PDF, Word, etc. etc.) There is basically what I would
have called a "mainline" in my COBOL days - I suppose we might call it a
driver these days? - that kicks everything off.

Now, a few of the classes need database access - for example, I store
information about references there - and several of the classes have the
potential of generating log messages.

I'm trying to figure out when I should initialize the logging and
database connection.

I'm leaning toward getting my database connection in the constructor of
the "mainline" and then passing that connection to each of the classes
that needs it as it is invoked in the mainline. I'm also leaning toward
getting my logger during the constructor of the mainline and, again,
passing it to each of the classes kicked off by the mainline.

This ensures that both the connection and logger are available to any
class that needs it. I'm also thinking that if creating the logger or
getting the database connection is a problem, I should probably find out
right at the start and probably abort the whole program if either one has
a problem. I'm inclined to think that if I'm unable to generate log
messages when I want to write them, that I shouldn't even get started.
The database connection is a little less categorical; if it is not
available, I could conceivably generate the resumes and simply display a
message to say that the references are not currently available so try
again later.

On the other hand, there are some classes that won't ever need to log -
little convenience classes that don't have any reason to throw exceptions
- and some of the work could be done even without the database connection
being there. Also, an argument might be made to the effect that the
classes that need database access (or even the logger) could simply
create their own _when needed_. That would also simplify the code
somewhat; if I do create the logger and database connection right at the
start and pass them to each and every class, then I add two extra
parameters to each constructor making more clutter than may be viewed as
strictly necessary.

What do you folks do in comparable situations?

I have a feeling I'm thinking of this too much like a COBOL programmer
and not enough like an OO/Java programmer.....

Both logging and database are rather well known problems with well known
solutions.

For logging I would say no central initialization at all, but let
the logging stuff read the configuration file at first call and
initialize.

For database you can either do something similar like have the
create connection code read the database configuration when needed
or if it is a heavy multithreaded app (does not sound like it) then
use a connection pool. A connection pool could also be initialized
at demand, but iy would be easier to justify initializing that at
startup.

Arne

 

[Lew]

You initialize logging via the framework, but you initialize a logger
separately for each class, or perhaps each instance.

You initialize the database setup when you load the driver, once, but not the
connections.

No.

Loggers are essentially self-initializing when the Logger class initializes.
Likewise the database driver. But not individual logger instances and not
individual DB connections.

DB connections can drop at any time. Past checks are no guarantee against
future exceptions.

The logging framework does that already.

There is a difference between initializing the database driver and using a
particular connection. You don't really need to create one and only one
connection yourself - that's what a connection pool handles for you.

Don't reinvent the wheel.

I also don't know if connections can be managed very well if they're being
used all over the place at once. The recommended pattern is to obtain one,
use it and close it right away to release resources held by Statements and
ResultSets and the like. For example, how would you interleave separate
transactions? What if you needed different transaction isolation?

Both logging and database are rather well known problems with well known
solutions.

For logging I would say no central initialization at all, but let
the logging stuff read the configuration file at first call and
initialize.

For database you can either do something similar like have the
create connection code read the database configuration when needed
or if it is a heavy multithreaded app (does not sound like it) then
use a connection pool. A connection pool could also be initialized
at demand, but iy would be easier to justify initializing that at
startup.

Connection pools are essentially self-initializing - you use a pooling driver
and then just pretend each new connection really is new and not recycled.

 

[Arne Vajhøj]

Connection pools are essentially self-initializing - you use a pooling
driver and then just pretend each new connection really is new and not
recycled.

It can be self initializing like logging, but occasionally the
pool is initialized at startup.

In some server contexts that is good for response time for the
first user, because initializing a connection pool can take
some time.

Arne