Centralizing instantiation?

Discussion in 'Java' started by Rhino, May 25, 2010.

  1. Rhino

    Rhino Guest

    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.....

    --
    Rhino
     
    Rhino, May 25, 2010
    #1
    1. Advertising

  2. Rhino

    Arne Vajhøj Guest

    On 25-05-2010 16:55, Rhino wrote:
    > 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
     
    Arne Vajhøj, May 25, 2010
    #2
    1. Advertising

  3. Rhino

    Lew Guest

    Rhino wrote:
    >> 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.


    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.

    >> 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.


    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.

    >> 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


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

    >> 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 logging framework does that already.

    >> 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.


    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?

    Arne Vajhøj wrote:
    > 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.

    --
    Lew
     
    Lew, May 26, 2010
    #3
  4. On 25-05-2010 19:07, Lew wrote:
    > Arne Vajhøj wrote:
    >> 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.


    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
     
    Arne Vajhøj, May 26, 2010
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Keith Patrick

    Centralizing MasterPage and Theme

    Keith Patrick, Nov 18, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    389
    Keith Patrick
    Nov 18, 2005
  2. D. Shane Fowlkes
    Replies:
    6
    Views:
    467
    D. Shane Fowlkes
    Feb 14, 2006
  3. Guest
    Replies:
    8
    Views:
    372
    Steven Cheng[MSFT]
    Dec 29, 2006
  4. Replies:
    1
    Views:
    587
    Salt_Peter
    Dec 25, 2006
  5. DK

    Centralizing Code Question

    DK, Dec 30, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    440
    Eliyahu Goldin
    Dec 31, 2007
Loading...

Share This Page