Debate: Inner classes or public classes with package access?

[Christian Bongiorno]

I am a fan of Inner class. Names Inner classes that is. The un-named
kind are not fit to see the light of day.

Ok, that being said, I find myself in a situation where I have
numerous Inner support classes, all of them are related to events,
JTables and such that exist in my display. (the current working outter
class).

However, having 15 inner classes has become tedious to manage at times
and ties your hands slightly (for example, you can't use static in an
inner class if you want a singleton model).

The closest alternative I could think of was to put them in their own
package and then have "package" access to most of those methods.

However, doing that forces me to grant public access to some of the
members in a class that would otherwise be private since, they are
useless outside of my Main panel window.

I am just curious as to what the current consensus is on this topic.
From an OO standpoint? From a supportability standpoint? Cleanliness?
Access standpoint?

Christian

 

[P.Hill]

However, doing that forces me to grant public access to some of the
members in a class that would otherwise be private since, they are
useless outside of my Main panel window.

You got something against default (package) access?

"The default access is that a member can be accessed anywhere within the package
that contains its declaration; other possibilities are public, protected, and
private."

-- JLS Chapter 6
http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html

 

[Oscar kind]

I am a fan of Inner class. Names Inner classes that is. The un-named
kind are not fit to see the light of day.

Anonymous inner classes can be ideal to connect for example Swing
interface components to your application. Of course, such an inner class
is not likely to implement more than one method.

Ok, that being said, I find myself in a situation where I have
numerous Inner support classes, all of them are related to events,
JTables and such that exist in my display. (the current working outter
class).

However, having 15 inner classes has become tedious to manage at times
and ties your hands slightly (for example, you can't use static in an
inner class if you want a singleton model).

Using named inner classes for such tasks creates extra work: you define
and instantiate them in different places, and they still don't need more
than one member function to call the API of your business model layer.

IMHO, this is the cause for the tediousness.


[...]

I am just curious as to what the current consensus is on this topic.
From an OO standpoint? From a supportability standpoint? Cleanliness?
Access standpoint?

My opinions on the matter:

OO:
Don't locate the support classes in a different package. In fact,
because of the minimal content required, inner classes are ideal.

Supportability:
Using anonymous inner classes defines a simple class with (often) one
method right where it's used. And since such code is not often reused
-- a GUI rarely has several buttons that do exactly the same -- there
is no code duplication.

Cleanliness:
For me an anonymous inner class is a clear winner to handle events in
a GUI:
- it's s simple construct for a trivial task (calling your business
model layer to perform business logic)
- it does almost nothing, so it doesn't interrupt the flow of the code
- Since it's anonymous, there only is the public API of it's interface
and/or superclass. Also, it can only access method parameters or
final members of the defining class. Thus there are no problems of
accessing too much or too little information.

Access:
Your original inner classes are a good idea. So are anonymous inner
classes.

 

[Christian Bongiorno]

In my original post you'll notice I suggested this very idea. However,
the main window needs access to some of the members of those classes.
The only way to do that is to make them public -- however, doing that
opens them up to the entire world. I would be forced to have no access
or too much.

Christian

 

[David Hilsee]

In my original post you'll notice I suggested this very idea. However,
the main window needs access to some of the members of those classes.
The only way to do that is to make them public -- however, doing that
opens them up to the entire world. I would be forced to have no access
or too much.

Why don't you put the main window class and the helper classes in the same
package, and specify package-level access for the members that need to be
accessed by your window? I think that's what P. Hill was asking.

 

[Chris Uppal]

Why don't you put the main window class and the helper classes in the same
package, and specify package-level access for the members that need to be
accessed by your window?

Especially as that's what the inner classes will be translated into anyway.

-- chris