Inner class

[Ben Kingsly]

What is the need for inner class, its advantage, where to use and how to use?

[Steve Morrow]

The Java� Tutorial - Inner Classes

[Dale Seng]

That is a big question, and I agree the tutorial would be in order. But for a quick introduction I can say that sometimes there's the need to do your implementation right there... on the spot. Yes, you could have a separate class, instantiate it, and use it, but if you're just going to throw it out immediately anyway, and it's just a small bit, it might be convenient to implement it on the spot. It might be easier to see with some examples. Search for code with the window closing event stuff and you'll find little examples with file filters. Try coding one of those with an inner class versus regular class and see which one you like better. Some people find inner classes "messy" looking. I usually avoid them unless it's a "traditional use" (easily recognized by the next poor slob who inherits my code).

[Layne Lund]

I often use anonymous inner classes for event handling. In fact, I think this is one of the "traditional uses" that Dale is referring to. However, there are also inner classes with names. Typically this type of inner class is used to show that there is a tight relationship between the two classes. This relationship would not be so obvious if the inner class were implemented as a regular top-level class. The Java API has some good examples of this. For instance, the Map interface from the Collections Framework has an inner class named Entry that contains (key, value) pairs from a Map. I can't think of any use of this Entry class that does not also directly use the Map class as well. That's probably why they made it an inner class.

I also agree that the tutorial will be a good place to start. Let us know if you have any specific questions about the information there.

Keep Coding!

Layne

[sever oon]

Direct implementation of an interface, typically an event listener, is what I usually use inner classes for. If you're writing a big class and you've provided a method that should be called when a button is clicked on the UI, you can have your class implement the ButtonListener (or whatever it's called) interface.

But is your class a button listener? Well, obviously it's interested in when a button is clicked for this particular application, but if it doesn't really make sense for it to define itself as a button listener in other contexts, then you probably don't want to identify it as such by having it implement that interface. In my way of thinking, the code that handles a bunch of UI events may happen to be in a class--that doesn't mean that class should implement 20 different event listener interfaces itself. That pollutes the inheritance hierarchy.

Much cleaner is to implement an anonymous inner class that implements the ButtonListener interface and register that inner class as an event handler on the button. The advantage of doing this is that this inner class can now forward to a private method in the enclosing class that handles the event without polluting the enclosing class' inheritance hierarchy.

Other uses for inner classes center around "friend" type relationships in C++, but without all the problems that C++-style friendliness carries along with it.

One thing you should be aware of is that if you define an anonymous inner class in a method, it may not use variables local to that method scope unless they are marked final. If you think about this for a while, it will make sense, but it throws a lot of people at first.

[Ben Kingsly]

Thank U.