Readers ponder the virtues (and defects) of anonymous inner classes

When I put up this last poll, it crossed my mind that a straightforward programmatic question (read: no mention of the mega companies’ mishaps, misdeeds, or missteps) wouldn’t generate much interest among our readers. Silly me. You are developers after all, and the fundamentals really do matter to you. Thanks. You’ve renewed my faith.

The topic for this survey actually came down to me from Design Techniques columnist Bill Venners. (Thanks, Bill!) He wanted to test the waters to see if anonymous inner classes were a viable topic for his column.

I asked readers to consider the idea of anonymous inner classes in the context of maintaining another developer’s code. Here’s what they had to say:

• 55% don’t mind anonymous inner classes as long as they’re small

• 19% don’t have any problem with anonymous inner classes, whatever their size

• 19% dislike anonymous inner classes because they make the code too hard to read

• 5% were unsure, or didn’t have a strong opinion

Looks to me like Design Techniques will be featuring anonymous inner classes as its subject sometime soon. Of the over 1,335 voters, 74 percent, or 988 people, feel anonymous inner classes are just short of a miracle. Of course, nothing is ever cut and dried. Bill will have to sift through the spectrum if he wants to learn why some readers are skeptical and others find the thought of anonymous inner classes positively vile. Well, maybe not vile, but some feel that the introduction of anonymous inner classes in JDK 1.1 gives Java’s OO framework a big, fat kick in the pants. We’ve culled some of the more interesting comments from the poll page. To see more, head to our archive of past polls. And, of course, don’t forget to voice your opinion in our latest poll.

I don’t mind anonymous inner classes as long as they’re small (55%):

I find that anonymous inner classes actually enhance readability when they’re small. It’s better to see the functionality “right there” than to scan the file for the definition of a named inner (or non-inner) class. I find them useful not only for the “classical” adapter user, but also for such things as simple Thread classes.

Nice feature, ugly syntax.

The key word here is anonymous. In my view, these classes are meant to be used only by the class in which they are contained. Super classes should only make use of these classes through well-defined interfaces. They are a very powerful tool for hiding complexity, but can be abused.

Inner classes allow placement of event handlers where they belong — with the initialization code for the event source (Component).

It’s true that they can make code hard to read; it’s up to the programmer to use them intelligently.

As a teacher of Java programming, and as a developer, I advocate using anonymous inner classes when: 1) The intent of the code is clearly commented, and 2) the result is only one simple method body. As with all such “syntactic sugar,” whether the use of anonymous inner classes creates a maintenance problem is largely up to the way they are used.

They’re great for creating custom listeners without cluttering up the package namespace

Anonymous classes allow you to implement a clean and clear design. They should be used, and they should be small.

Anonymous inner classes are the best mechanism for event dispatching. However, the actual work completed after the dispatch belongs in another method.

I do think that it makes the code a bit harder to read, but they’re so useful that it makes up for the trouble. However, if you end up with inner classes spanning dozens of lines, it probably would be much easier for everyone to move them to a named inner class. One thing, though, it’s really hard to decide how to indent anonymous inner classes. If you think bracket alignment in C was a religious subject, just imagine what happens with anonymous inner classes.

I don’t have any problem with anonymous inner classes whatever their size (19%):

Anonymous and inner classes are the reason I finally left all those other programming languages behind! I used to miss the block structures of Pascal and function pointers of many other languages. I can now use anonymous/inner classes to accomplish the same tasks. Additionally, using anonymous classes to make small changes to class functionality instead of creating a plethora of trivial subclasses actually makes class libraries less cluttered and much easier to understand.

Anonymous inner classes (especially interface implementations) are a fantastic feature that has tremendously improved the usability of Java.

Inner classes might be a little painful to parse, but they make code much more readable if you use them right. Things like

Runnable r = new Runnable() { 
   public void run() { 
   //do this, do that 
   } 
}
Thread t = new Thread(r); t.start(); 

are much more elegant and readable than anything you can achieve by using normal classes. The same for event handlers.

Like many other techniques, they are wonderful when used correctly (and well documented), but deadly if abused. The potential for abuse should not make us forego a very useful technique. Anonymous inner classes should almost always be small, and should not be overused, but if a particular situation is bizarre enough to justify placing the bulk of an application in one or more anonymous inner classes, then it should be done — and the reasons for doing so strange a thing should be right there in the source.

Inner classes — including the anonymous ones — are a powerful tool and a programming asset. It’s up to the programmer to write readable code.

Your poll left out, I totally love anonymous inner classes! In my opinion using anonymous inner classes is critically important for organizing source code. Using inner classes, you are able to see exactly how the widget is created and how it functions. Although long anonymous inner classes can be difficult to read if good indentation and documentation practices are not followed, in general Java GUI construction and code maintenance would be much harder without them.

Anonymous inner classes are indispensible, in that they provide one more level of access restriction. The variety of options available to Java to provide many levels of scope and access are one of its greatest features from a designer’s perspective.

I dislike anonymous inner classes because they make the code too hard to read (19%):

Give us blocks like we had in Smalltalk. Inner classes are an offensive hack that brutalize readability in an already overly cryptic language. If I want to obfuscate my code I’d use C.

Java was specifically designed to be a clear, readable and uncluttered language. The use of anonymous inner classes breaks many of the very rules that the initial versions of Java were so proud of. They’re yucky (that’s a technical term).

Inner classes, while very useful, are really only a poor substitute for privileged access, as can be specified in C++ (via friends) or in Eiffel (the neatest solution). It’s a shame the designers took the inner class route, as classes do indeed become more difficult to understand the more information is packed into them.

Not only do I dislike them because they hurt both readability and maintainability, but I have banned their use by all developers in my company. Any use of them will cost my developers a 00 fine and they’ll have to fix the code.

I have three issues with inner classes. First, they break encapsulation, making them a no-no in OOP, and causing me to wonder how they made it into Java in the first place. Second, the end result for performance is equivalent to or worse than making a separate java file, or adding the class to the bottom of an existing java file. Finally, inner classes are hard to maintain, since their code is intrinsically wrapped with other code. You can’t just open the file for a small adapter class and change it. Instead you open a big class file, try to find the inner class (Don’t forget you may not even have a name to search for) and edit it in place, possibly introducing a host of bugs to the parent along the way. Basically, they don’t give me any new functionality except a way to break encapsulation and program poorly.

Having seen these things used all over some code that our company is developing, I’ve come to hate them with a passion. Readability is shot, and debugging nearly impossible as line numbers reported in error messages often don’t match where errors are actually occurring. One of the worst “features” (if not the worst feature) added to Java.

Trivial or careless use of classes can add a significant overhead to an application in terms of both size and performance.

Reflection and inner classes are kludges for Java’s lack of the equivalent of method pointers.

Don’t know/no opinion (5%):

I’ve never heard of anonymous inner classes, so I’m almost sure we don’t need them.

We need pointers.