Robert Simmons continues his efforts to clarify confusion over the use of nested classes in Java in this week’s installment, excerpted from Chapter 6 (“Nested Classes”) of Hardcore Java. Robert discusses the somewhat troublesome limited-scope inner classes; one specific type within this category, known as anonymous classes; and the various problems programmers can encounter with limited-scope classes.
Nested Classes, Part 2
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
that ActionListener class thing is horrible. it’s much better to have one ActionLister assigned to everything so you know that there’s only one place to look if there’s a problem with any of the GUI elements.
that ActionListener class thing is horrible. it’s much better to have one ActionLister assigned to everything so you know that there’s only one place to look if there’s a problem with any of the GUI elements.
Agreed. Would you come back six months from now and look at that? It is much better to have one ActionListener, but I have never liked Java for this sort of thing anyway and I have never liked how you go about capturing events. The language could help out a bit. I just get the impression Sun have lost it a bit with Java.
C# and additions like delegates introduce ways of cleaning things like this up.
i still prefer java over c# for the simple reason that java is more portable. you can’t trust microsoft to provide a completely platform independent language.
“java!”
“no! C#!!”
“no! no!!” java!!!”
and on and on we go. change the record guys (or stick to the topic – nested classes in java in case you have forgotten) because this argument is getting very boring.
i still prefer java over c# for the simple reason that java is more portable. you can’t trust microsoft to provide a completely platform independent language.
We’re just talking about the languages here – not the platforms.
this was just an example to show how nested classes work, but nothing’s stopping you from defining a top-level class inherinting from ActionListener and telling every single one of your GUI elements to use that class as the event handler. I believe that the ActionEvent parameter that the ActionListener receives carries a reference to te sender so from that moment on it’s pretty easy to know who the sender is…
All said, I also dislike nested classes
I always thought OOP meant also obect reuse and here we’re just defining a class pretty much for the sake of the sake. The only advantage being that they can access ‘final’ elements and so on, but I’m not sure if that’s worth the hassle!
Anonymous inner classes aren’t Java mainstream, but it’s funny to watch people complain about their limitations without learning how they might be used in the first place. Anonymous inner classes can be reused just fine by returning instances from other methods based on parameters. Again, might not want to do much of this in Java because it looks abnormal, but there’s nothing really fundamentally wrong with it.
Also, get a refactoring browser such as Eclipse, and it can convert things to named classes mostly automatically.
As a side comment on this, a refactoring mentality simplifies a lot of traditional design issues. Unless you need to publish your API, of course.
I quite like the concept of nested classes in Java, but agree they need to be used in the right way.
I spend alot of time developing in C, C++, Java and a pure OOP language called Magik.
Where there is no framework available, providing for good event notifications, databuses, providers etc. and/or I’m writing something small & tight which needs to have external hooks available or used across different frameworks then providing for nested classes (in Java) is a good KISS way to go.
Typically I use nested classes to dispatch the method to an appropriate handler on a framwework or higher-order class. In C/C++ I’d probably pass a function pointer in and in Magik i’d either use a stand-alone procedure or the equivalent of nested-class.
I tend to find that if the semantics of the code are clear and the code is appropriately documented (not just the actual code but the design) then the argument regarding support is irrelevant … after all many of the support developers I known find it easier to grasp the concept of a nested class than the intricies of many of the event dispatch and handling mechanisms in the variety of frameworks that are available.