Over-Engineering?
Last night I was looking through some of the Java 1.5 API documentation, and I discovered the java.io.Closeable interface. “A Closeable is a source or destination of data that can be closed.” And, you guessed it, the Closeable interface has exactly one method: close().
Thanks! How in the world did we get through five major Java releases without having this interface? I have no idea…
Then I discovered a second Java 1.5 addition, java.io.Flushable. Again, it has exactly one method: flush().
Now, this definitely strikes me as an obvious case of over-engineering. If closing or flushing an object were a lengthy procedure that required some level of attention, then I could see the justification for having a couple of special interfaces. In that case, Closeable and Flushable would each have a couple of methods to track the closing or flushing operation, and it would be really obvious why “It’s such a good idea to have these interfaces!”
However, as it stands, I can’t find a single method in the Java 1.5 API that actually takes an argument of either Closeable or Flushable; they are only used in class-declarations for the java.io and java.nio.* packages. So, presumably, somebody thought it would be a Good Idea, and that was that!
Of course, now we need to have a javax.swing.Closeable interface, for all of the different UI-widgets that can be closed. I mean, how are you supposed to know whether you can close a particular UI-widget? Dialogs and windows and frames cry for a special Closeable interface of their own.
Finally, can somebody explain to me why java.net.Socket doesn’t implement java.io.Closeable? It has a close() method - an obvious candidate for this special new interface.
January 12th, 2006 at 8:19 am
Just discovered the Closeable IF and that Sockets aren’t closeable. For the former - I actually find it very useful in a mini-appserver to have a controller manage the shutdown of its components and able to close anything theyve registered as requiring tidying up - it cleans up the component implementation. Previously I did this with reflection - which sometimes threw out Security exceptions on - guess what - sockets!!! So THAT piece of code hasn’t got any nicer, but the Closeable in general does have its uses. By the same token, I can see the use of Flushable by a controller that needs to flush closeable resources before closing them.