Design patterns for resource management

Discussion in 'Java' started by Mark Rafn, Aug 29, 2007.

  1. Mark Rafn

    Mark Rafn Guest

    I'm more of a Java person than a C++ guy, but I'm becoming increasinly aware
    of the contortions Java is forcing me into because of a lack of destructor
    (partly because I'm having to defend them to C++-centric coworkers). I
    understand the performance reasons for using the purer GC model, but
    I'd give them up in a lot of cases for easier-to-manage scoping of resource
    use.

    For Connection, Socket, and other heavy resource-consuming objects, the
    standard Java pattern is try/finally - acquire the resource in a try and
    release it in a finally. The problem is that this is NOT required for most
    objects, and it leaks implementation details up a level: now a user of an API
    needs to treat an object very differently based on what resources it uses.

    In a lot of cases, I'd much prefer C++ style scoping, where an object can be
    created, used, and it will automatically be destructed when the scope leaves.
    The user of the object doesn't need to know that cleanup is needed, and
    therefore an explicit try/finally.

    Every time I've gone down the road of making an API more encapsulated WRT
    whether or not it holds heavyweight resources, I end up causing more bugs than
    I prevent, and go back to the simple methodology of requiring my caller to
    know that close() is required.

    Anyone have any suggestions for better patterns, or should I just get over
    this and learn to love try/finally and explicit close() methods?
    --
    Mark Rafn <http://www.dagon.net/>
     
    Mark Rafn, Aug 29, 2007
    #1
    1. Advertising

  2. Mark Rafn

    Daniel Pitts Guest

    On Aug 29, 10:13 am, (Mark Rafn) wrote:
    > I'm more of a Java person than a C++ guy, but I'm becoming increasinly aware
    > of the contortions Java is forcing me into because of a lack of destructor
    > (partly because I'm having to defend them to C++-centric coworkers). I
    > understand the performance reasons for using the purer GC model, but
    > I'd give them up in a lot of cases for easier-to-manage scoping of resource
    > use.
    >
    > For Connection, Socket, and other heavy resource-consuming objects, the
    > standard Java pattern is try/finally - acquire the resource in a try and
    > release it in a finally. The problem is that this is NOT required for most
    > objects, and it leaks implementation details up a level: now a user of an API
    > needs to treat an object very differently based on what resources it uses.
    >
    > In a lot of cases, I'd much prefer C++ style scoping, where an object can be
    > created, used, and it will automatically be destructed when the scope leaves.
    > The user of the object doesn't need to know that cleanup is needed, and
    > therefore an explicit try/finally.
    >
    > Every time I've gone down the road of making an API more encapsulated WRT
    > whether or not it holds heavyweight resources, I end up causing more bugs than
    > I prevent, and go back to the simple methodology of requiring my caller to
    > know that close() is required.
    >
    > Anyone have any suggestions for better patterns, or should I just get over
    > this and learn to love try/finally and explicit close() methods?
    > --
    > Mark Rafn <http://www.dagon.net/>



    Often, I end up writing a "wrapper" class and use "command" pattern.


    public final class ResourceManager {
    public <E> E execute(ResourceOperation<E> ro) throws Exception {
    final Resource res = acquireResource();
    try {
    final E result = ro.execute(res);
    return result;
    } finally {
    disposeResource(res);
    }
    }
    }

    Where ResourceOperation is an interface that represents an atomic
    action on a resource.

    This works in most cases. Its a little bit of code overhead if you
    only use it once, but it is better if you have the same idiom
    repeatedly.

    Its also an example of Inversion of Control. You're code is now
    decoupled from the exact means of acquiring and disposing the
    resource.

    Yes, it is more code then the equivalent C++, but personally, I'd
    rather know explicitly that the acquiring and disposing of the object
    is handled, rather than guessing that the destructor should do it.
     
    Daniel Pitts, Aug 29, 2007
    #2
    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. Dirc Khan-Evans
    Replies:
    1
    Views:
    902
    Karl Seguin
    Oct 17, 2005
  2. avishosh
    Replies:
    2
    Views:
    10,579
    avishosh
    Aug 8, 2004
  3. crichmon
    Replies:
    4
    Views:
    486
    Mabden
    Jul 7, 2004
  4. Tim Smith
    Replies:
    2
    Views:
    856
    Tim Smith
    Dec 15, 2004
  5. John
    Replies:
    0
    Views:
    598
Loading...

Share This Page