I have long held the opinion that the feature of anonymous inner classes in Java (and, truly, any language) are an abomination, an unnatural perversion having no place amongst all things Holy and True. There are others who share this opinion of mine, for various reasons.
My primary reason for having such a severe dislike of those things is because they completely destroy the flow of the code. In the middle of a method -- nay! even worse -- in the middle of a method call, suddenly there's code being laid out which will be executed in some other flow, most likely through some other thread -- nay! still worse -- suddenly there's another class being defined! Lordy lord, what horrible thing to do to your code!
Let's look at a simple little example:
EEEK! Don't do that! Blech! Blech! Blech!
Instead, consider something like this:
Ahhhh. Much better. Just the act of turning that anonymous inner class into a named inner class worked magic on that little snippet of code.
That particular inner class only sported one line of meaningful code. Now imagine if the code in the inner class had to be a bit more involved. Even if the inner code were as small as 5 lines, the impact is still staggering.
You know, when all is said and done, the thing that really confuses me about this is that it seems most Java engineers don't even notice, or perhaps simply don't care, about the defilement they are incorporating into their very own code.
My primary reason for having such a severe dislike of those things is because they completely destroy the flow of the code. In the middle of a method -- nay! even worse -- in the middle of a method call, suddenly there's code being laid out which will be executed in some other flow, most likely through some other thread -- nay! still worse -- suddenly there's another class being defined! Lordy lord, what horrible thing to do to your code!
Let's look at a simple little example:
public class FindConfigFiles
{
public void loadConfigFiles (File basePath)
throws IOException
{
File[] configFileLIst = basePath.listFiles(new FileFilter ()
public boolean accept (File toCheck)
{
return toCheck.getName().endsWith(".xml");
}
);
:
}
}
{
public void loadConfigFiles (File basePath)
throws IOException
{
File[] configFileLIst = basePath.listFiles(new FileFilter ()
public boolean accept (File toCheck)
{
return toCheck.getName().endsWith(".xml");
}
);
:
}
}
EEEK! Don't do that! Blech! Blech! Blech!
Instead, consider something like this:
public class FindConfigFiles
{
static protected class ConfigFileFilter
implements FileFilter
{
public boolean accept (File toCheck)
{
return toCheck.getName().endsWith(".xml");
}
}
public void loadConfigFiles (File basePath)
throws IOException
{
File[] configFileLIst = basePath.listFiles(new ConfigFileFilter());
:
}
}
{
static protected class ConfigFileFilter
implements FileFilter
{
public boolean accept (File toCheck)
{
return toCheck.getName().endsWith(".xml");
}
}
public void loadConfigFiles (File basePath)
throws IOException
{
File[] configFileLIst = basePath.listFiles(new ConfigFileFilter());
:
}
}
Ahhhh. Much better. Just the act of turning that anonymous inner class into a named inner class worked magic on that little snippet of code.
That particular inner class only sported one line of meaningful code. Now imagine if the code in the inner class had to be a bit more involved. Even if the inner code were as small as 5 lines, the impact is still staggering.
You know, when all is said and done, the thing that really confuses me about this is that it seems most Java engineers don't even notice, or perhaps simply don't care, about the defilement they are incorporating into their very own code.
Leave a comment