It might be efficient, but it ain’t OO
Should you favor optimization or good OO design in your Java programs?
February 22, 2002
Q: Recently, I was told not to use anonymous inner classes to associate listeners with specific screen components, but instead implement the ActionListener interface in the class declaration and handle the events in the actionPerformed() method because it is more efficient. Is that true?
A: In my opinion, from a stylistic viewpoint, implementing the ActionListener in the class declaration is just ugly. You end up with one monolithic method forced to handle every component that generates action events.
It’ll look something like this:
if( e.getActionCommand().equals( "some text" ) )
{
// do domething
}
else if( e.getActionCommand() ... etc, etc, etc
From an object-oriented (OO) perspective, this just isn’t OO. Is it more efficient? I suppose from a memory perspective it could prove more efficient because you’re not creating extra objects. However, if you’re dealing with a large number of components, it might be faster to dispatch directly to the proper object than to switch through each case.
I normally wouldn’t do this as an anonymous class either, but that is just a style judgment. I like to keep anonymous classes short. In fact, I use anonymous classes only when I require the value of an argument that is passed into the method where the class is defined.
Instead of anonymous classes, I normally create a number of inner classes — one corresponding to each component. Sure, I pay for the extra memory for the objects, but I avoid the ugly if/else mess you get into by declaring one monolithic actionPerformed() method.
As a rule of thumb, I always favor style and good architecture over some nebulous idea of efficiency. Then, once I’m done (or as problems present themselves), I optimize where optimization is needed. I always ask: if you’re not willing to program in an object-oriented manner (because of efficiency or whatever reason), why are you programming in Java?
Now, I can see the emails already. My rule of thumb doesn’t mean you completely ignore efficiency. You should still strive to use ArrayLists over Vectors, String buffers over concatenation, and so on. However, don’t blind yourself in the name of optimization.
In his book, Effective Java, Joshua Bloch writes about optimization, “Don’t sacrifice sound architectural principals for performance.” Often, optimizations result in difficult-to-understand, difficult-to-maintain, and fragile code. Bloch stresses the fact that a good architecture lets you optimize as the need arises.
