Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Debate: Inner classes or public classes with package access?

Reply
Thread Tools

Debate: Inner classes or public classes with package access?

 
 
Christian Bongiorno
Guest
Posts: n/a
 
      08-27-2004
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
 
Reply With Quote
 
 
 
 
P.Hill
Guest
Posts: n/a
 
      08-28-2004
Christian Bongiorno wrote:
> 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/s...names.doc.html

 
Reply With Quote
 
 
 
 
Oscar kind
Guest
Posts: n/a
 
      08-28-2004
Christian Bongiorno <(E-Mail Removed)> wrote:
> 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.


--
Oscar Kind http://home.hccnet.nl/okind/
Software Developer for contact information, see website

PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
 
Reply With Quote
 
Christian Bongiorno
Guest
Posts: n/a
 
      08-29-2004
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

"P.Hill" <(E-Mail Removed)> wrote in message news:<cgokrm$a3g$(E-Mail Removed)>...
> Christian Bongiorno wrote:
> > 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/s...names.doc.html

 
Reply With Quote
 
David Hilsee
Guest
Posts: n/a
 
      08-29-2004
"Christian Bongiorno" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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.

--
David Hilsee


 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      08-30-2004
David Hilsee wrote:

> 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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola MCSE 4 11-15-2006 02:40 AM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola Microsoft Certification 3 11-14-2006 05:18 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola MCSD 3 11-14-2006 05:18 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd realexxams@yahoo.com Microsoft Certification 0 05-10-2006 02:35 PM
microsoft.public.dotnet.faqs,microsoft.public.dotnet.framework,microsoft.public.dotnet.framework.windowsforms,microsoft.public.dotnet.general,microsoft.public.dotnet.languages.vb Charles A. Lackman ASP .Net 1 12-08-2004 07:08 PM



Advertisments