 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Matt Tyler
Guest
|
 Posted: Sat Jan 24, 2004 12:01 pm Post subject: Nested/inner classes and general style |
 |
|
Hi,
I am fairly new to OO/Java development but have a backgroung using
procedural based languages. I have a few 'style and correctness' questions
and hope that maybe you could offer me some advice. These may seem a bit
fussy but I am trying not to develop any habits.
1. Nested/inner classes.
I uderstand these are used when a class makes sense only within a containing
class and the inner class needs access to the containing class
methods/variables. Is it good practice to use them? I'll outline my reson
for asking.
For example, An animal class may contain a brain class. The brain class may
want to call methods within the Animal class such as MoveLimb() etc. All
well and good but how do you specify that the method you are calling belongs
to the outer class when you can't use this.MoveLimb()? I realise that you
could just use MoveLimb() but this does not make it clear which class the
method is a member of. If you have several levels of nesting this will only
add to the confusion.
2. If a method requires a lot of parameters (in my old life) I would enclose
them in a structure if they could be logically grouped. I don't like writing
methods/constructors with long parameter lists because it seems somehow
inelegant. If I created a class containing the variables I would of course
need a constructor with a parameter list just as long!
As you can see I miss my structures!
Is it 'the done thing' in Java to have methods/Constructors with long input
parameter lists? If not then I am missing a point somewhere and some advice
would be appreciated!
Many thanks for any advice given.
Matt
|
|
| Back to top |
|
 |
Oscar Kind
Guest
|
| Posted: Sat Jan 24, 2004 12:58 pm Post subject: Re: Nested/inner classes and general style |
|
|
Matt Tyler <matt_tyler (AT) blueyonder (DOT) co.uk> wrote:
| Quote: | 1. Nested/inner classes.
I uderstand these are used when a class makes sense only within a containing
class and the inner class needs access to the containing class
methods/variables. Is it good practice to use them? I'll outline my reson
for asking.
For example, An animal class may contain a brain class. The brain class may
want to call methods within the Animal class such as MoveLimb() etc. All
well and good but how do you specify that the method you are calling belongs
to the outer class when you can't use this.MoveLimb()? I realise that you
could just use MoveLimb() but this does not make it clear which class the
method is a member of. If you have several levels of nesting this will only
add to the confusion.
|
Assuming you use a private/protected method moveLimb(), your example is
very good. Another example would be callbacks from a user interface (see
the class JButton and the interface ActionListener): you create an
(anonymous) inner class that implements the interface as a callback.
A minor point though: don't start your method names with a capital letter.
The Java naming conventions are widely used and IMHO make code easier to
read:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
| Quote: | 2. If a method requires a lot of parameters (in my old life) I would enclose
them in a structure if they could be logically grouped. I don't like writing
methods/constructors with long parameter lists because it seems somehow
inelegant. If I created a class containing the variables I would of course
need a constructor with a parameter list just as long!
As you can see I miss my structures!
Is it 'the done thing' in Java to have methods/Constructors with long input
parameter lists? If not then I am missing a point somewhere and some advice
would be appreciated!
|
Personally, I hardly have long parameter lists (more than 5 parameters). The
reason is that in my designs I can avoid them:
- If parameters describe atrributes of an object, I can generally let that
object handle it, thus eliminating the parameters.
- If parameters are similar (environment variables), I use a Properties
object, thus reducing many parameters to one.
Note that the last option is most similar to structs, and can also be
applied to Object's instead of Strings. Note however, that altough this
approach is very generic, it is also far from easy to read. Avoid the need
for it if possible.
Oscar
--
No trees were harmed in creating this message.
However, a large number of electrons were terribly inconvenienced.
|
|
| Back to top |
|
|
Matt Tyler
Guest
|
| Posted: Sat Jan 24, 2004 6:15 pm Post subject: Re: Nested/inner classes and general style |
|
|
"Oscar Kind" <oscar (AT) danwa (DOT) net> wrote
| Quote: | Matt Tyler <matt_tyler (AT) blueyonder (DOT) co.uk> wrote:
For example, An animal class may contain a brain class. The brain class
may
want to call methods within the Animal class such as MoveLimb() etc. All
well and good but how do you specify that the method you are calling
belongs
to the outer class when you can't use this.MoveLimb()? I realise that
you
could just use MoveLimb() but this does not make it clear which class
the
method is a member of. If you have several levels of nesting this will
only
add to the confusion.
Assuming you use a private/protected method moveLimb(), your example is
very good.
|
Thanks, but it still does not make it explicitly clear which class
moveLimb() belongs to. If my brain class contains nested classes that invoke
moveLimb you can see how things soon become confusing. If an outer class
contains two or more levels of nesting is there any prefix that makes it
clear which class a called method belongs to? I have read that in effect an
inner class has two versions of this., one implied (referring to everything
within the outer class) and one referring to the current class.
Cheers
Matt Tyler.
|
|
| Back to top |
|
|
Daniel Leontiev
Guest
|
| Posted: Sat Jan 24, 2004 8:30 pm Post subject: Re: Nested/inner classes and general style |
|
|
try using this kind of class in place of structure, it is very simular to
structure
make all variables in it public
public class structureClass
{
public String value1 = "";
public int value2 = 0;
}
or create one abstract class and extend all of the classes that you want as
structures
public abstract class abstractStructure
{
public String name = "";
...
...
}
public class structureClass extends abstractStructure
{
//this class will automaticaly have the [ name ] variable
//it is inherited from the base class so you dont need to define it here
}
//later in the code you can pass all structure classes that are inherited
from
//the base class to a function that expects abstractStructure base class
public void test()
{
structureClass str = new structureClass();
str.name = "new structure";
//you can pass the structureClass here because it is inherited from
//abstractStructure base class
someFunction( str );
}
public void someFunction( abstractStructure struc )
{
//here you can test what subclass it is ( if you have several classes
inherited
//from abstractStructure base class
if ( struc instanceof structureClass )
{
//do something
}
else
if ( struc instanceof anotherStructureClass )
{
//do something
}
}
|
|
| Back to top |
|
|
Jon A. Cruz
Guest
|
| Posted: Sat Jan 24, 2004 8:34 pm Post subject: Re: Nested/inner classes and general style |
|
|
Oscar Kind wrote:
| Quote: | Matt Tyler <matt_tyler (AT) blueyonder (DOT) co.uk> wrote:
1. Nested/inner classes.
I uderstand these are used when a class makes sense only within a containing
class and the inner class needs access to the containing class
methods/variables. Is it good practice to use them? I'll outline my reson
for asking.
For example, An animal class may contain a brain class. The brain class may
want to call methods within the Animal class such as MoveLimb() etc. All
well and good but how do you specify that the method you are calling belongs
to the outer class when you can't use this.MoveLimb()?
|
This question is not quite so clear. If you just want to move the limb
and don't care, call moveLimb() from where ever you are.
If you're in some other method of Cell and decide that you need to move
a limb, just call "moveLimb()". It will be handled by Brain.moveLimb()
which can in turn call Cell.moveLimb().
Or... if you're in a method in the Cell class and want to explicitly
call the Animal version, just call "Animal.this.moveLimb()"
| Quote: | I realise that you
could just use MoveLimb() but this does not make it clear which class the
method is a member of. If you have several levels of nesting this will only
add to the confusion.
|
http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html
However... I'd say that in this specific case:
* This example seems a little confusing
* therefore, this might not be proper for inner classes.
For example, I myself would probably have Brain as a normal top-level
class that just needs an Animal instance passed in for it's constructor.
| Quote: | Another example would be callbacks from a user interface (see
the class JButton and the interface ActionListener): you create an
(anonymous) inner class that implements the interface as a callback.
|
This, I think, is one of the biggest uses of nestled classes. Sun's
developer info also pushes this as the primary use of them.
Short annonymous or regular inner classes with simple methods are some
of the best for listeners. Working as adapters they take listener
implementations off of the main class, and centralize code. For example,
when adding a button to a UI that needs to trigger something in the
parent class, just add an annonymous inner class based on ActionListener
that only has a single line method that turns around and calls a
specific method in the parent class.
This article has more info, especially under " The callback advantage"
http://www.javaworld.com/javaworld/javaqa/2000-03/02-qa-innerclass.html
| Quote: | Personally, I hardly have long parameter lists (more than 5 parameters). The
reason is that in my designs I can avoid them:
- If parameters describe atrributes of an object, I can generally let that
object handle it, thus eliminating the parameters.
- If parameters are similar (environment variables), I use a Properties
object, thus reducing many parameters to one.
|
I agree with this. However, there's another point in the middle of those
that I use in addition to those other two:
- If the parameters really can be grouped up logically and are needed
for construction, I can generally group them into a class or two of
their own and just pass instances of the classes holding those details in.
|
|
| Back to top |
|
|
Jon A. Cruz
Guest
|
| Posted: Sat Jan 24, 2004 11:35 pm Post subject: Re: Nested/inner classes and general style |
|
|
Matt Tyler wrote:
| Quote: |
Thanks, but it still does not make it explicitly clear which class
moveLimb() belongs to. If my brain class contains nested classes that invoke
moveLimb you can see how things soon become confusing. If an outer class
contains two or more levels of nesting is there any prefix that makes it
clear which class a called method belongs to? I have read that in effect an
inner class has two versions of this., one implied (referring to everything
within the outer class) and one referring to the current class.
|
There's a simple way to do that. But first I should go over why *not* to
use nestled classes, especially for a case like this.
The Java Tutorial says "You should define a class within another class
when the nested class makes sense only in the context of its enclosing
class or when it relies on the enclosing class for its function."
However, that does not mean that every case where those might apply is
good for inner classes. More that unless one of those applies then it
should not be an inner class at all.
Going on, let's think about your example. Maybe asking a few questions
can clarify things:
Does an instance of Brain always need to be in an Animal? Could one not
put an instance in some jar and hook up speakers to it? (well, yes I
know these are a bit silly, but do make the point of what to consider).
So, even though you *usually* have a Brain in an Animal, is it *always*
required to be so?
Does an instance of Brain always stay with one and only one Animal?
Could you perhaps do a brain transfer? Again, if in some cases the
answer could be 'yes', then it's not a good candidate for an inner class.
Could you want to subclass either Brain or Animal? Say for example that
you wanted to have ReptileBrain, HigherBrain, EnlightendBrain, etc.,
then it would be a little hard to manage your code to stick different
subclasses of Brain into different subclasses of Animal.
And if you wanted to take a non-nested approach, this might be one way:
public class Animal
{
Brain brain;
...
public Animal()
{
brain = new Brain(this);
....
public class Brain
{
Animal host;
...
public Brain( Animal host )
{
this.host = host;
}
....
public void skinTickled()
{
host->moveLimb();
....
But if you wanted to do things with nested classes...
class Cell
{
....
void synapseFooFired()
{
Animal.this.moveLimb();
}
But just remember, if you have more than a simple adapter, then it might
not be good to use a nested class.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
