Re: Design patterns for resource management
On Aug 29, 10:13 am, da...@dagon.net (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 da...@dagon.net <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.