Design patterns for resource management
- From: dagon@xxxxxxxxx (Mark Rafn)
- Date: Wed, 29 Aug 2007 10:13:54 -0700
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 dagon@xxxxxxxxx <http://www.dagon.net/>
.
- Follow-Ups:
- Re: Design patterns for resource management
- From: Daniel Pitts
- Re: Design patterns for resource management
- Prev by Date: JFrame bleed-through
- Next by Date: Re: TreeSet.contains and an OVERLOADED equals...works?
- Previous by thread: JFrame bleed-through
- Next by thread: Re: Design patterns for resource management
- Index(es):
Relevant Pages
|
