I have a class sosaIndex() that takes one parameter sosaRoot ; in this class
I have a contructor (method sosaIndex) that on instanciation calls a method
setIndexation based on sosaRoot.

When the first time I instancie to create an object called "aa" I have
this :
sosaIndex aa=sosaIndex(sosaRoot);

Now if I change the sosaRoot I can use :

(1) aa.setRoot(sosaRoot) if this method is part of class sosaIndex to change
the sosaRoot of the object "aa" instanciated.
and after this :
aa.setIndexation(sosaRoot)
to finish the job and eventually get my object "aa" up-todate,

but Java does not say anything wrong if I do again :

(2) sosaIndex aa=sosaIndex(sosaRoot);
I mean instancie a new object with the SAME NAME "aa".

Anything wrong with method (2) and what happens to the first
instanciation "aa" ?
Thanks.

Daniel Moyne <dmoyne@tiscali.fr> writes:
>I have a class sosaIndex() that takes one parameter sosaRoot ;

  Declarations of constructors or methods have parameters.

  Classes do not have parameters (except type parameters).

  Type names should start with uppercase letters.

>in this class I have a contructor (method sosaIndex) that on

  Constructors are not methods.

>instanciation calls a method setIndexation based on sosaRoot.

  Method calls do not have �bases�.

  You might have intended to the /target object/
  of a method invocation.

>When the first time I instancie to create an object called "aa" I have
>this :
>sosaIndex aa=sosaIndex(sosaRoot);

  To create objects, one usually uses an instance creation
  expression, which looks like �new CLASS(...)�

>but Java does not say anything wrong if I do again :
>(2) sosaIndex aa=sosaIndex(sosaRoot);
>I mean instancie a new object with the SAME NAME "aa".

  An local identifier can be declared only once within
  a block. But the same identifier might be declared
  in another block or other scope.

>Anything wrong with method (2) and what happens to the first
>instanciation "aa" ?

  If they have different scopes, they will not disturbe
  each other.

Daniel Moyne wrote:

> Anything wrong with method (2) and what happens to the first
> instanciation "aa" ?

Stefan has some good points.  Constructors are not methods.  They 
inherit differently, for example, and it's important to keep these 
differences in mind when designing classes.

I'm going to answer your question a bit differently than he did. There 
are a couple of different schools of thought when it comes to class 
design.  These schools of thought are not opposite or immiscible but 
rather complementary and both can be used in the same design.

First is Java Beans.  Real Java Beans (the full spec) are complicated, 
but the basic bean is pretty simple.  You have a default constructor and 
setters and getters which can be called to configure the class.  This is 
a bit like your sosaIndex class.

Your class:
   sosaIndex aa = new sosaIndex( sosaRoot );
   aa.setRoot( sosaRoot2 );
   aa.setIndexation( sosaRoot2 );

Bean:
   JLabel label = new JLabel();
   label.setText( "Hello World!" );
   label.invalidate();

On the other side of the coin there is something called POJO.  POJO 
stands for Plain Old Java Objects.  It's a design technique that 
emphasizes concrete objects which are instantiated completely by their 
constructor and then never touched.  This makes it possible to make 
these objects immutable (a big win in complex designs) and also reduces 
the chances that the programmer will use a series of setters that leave 
the object in an invalid state.

This means if you want a different object, you do have to make a new 
one.  That's a lot like your second example, where aa gets replaced by
There's probably a lot more to both sides than this, I'm just hitting 
the basics.

   aa = new sosaIndex( sosaRoot2 );

So which is better?  It depends.  If an object is difficult and 
expensive to construct, providing setters and getters might improve 
performance.  Swing objects have a fairly long inheritance tree, so in 
some ways it really does make sense to not construct them if it can be 
avoided.  There are also a myriad of configurations available for the 
average Swing object, which would require a confusing myriad of 
constructors to support if they went the POJO route, so again Beans win 
here by virtue of simplicity.

OTOH had, most designs are not as complex as Swing, and the overwhelming 
majority of objects in an application should probably be simple POJO 
objects.  KISS.  Keep It Simple Charlie.


Now on to your second question:  There's no difference between:
   int aa = 1;
   // use aa...
   aa = 2;

and doing the same for a class reference.  Except as you note a class 
has extra memory associated with it that needs to be disposed of.  When 
the JVM detects that you have removed all references of an object 
(technically it's any "reachable" reference by any thread in the JVM), 
it then will at some point garbage collect that object for you.

This normally works well, and with out you having to do anything about 
it.  If a class has some other external state associated with it (the 
ubiquitous example is an open file handle) the the finalize() method can 
be over-ridden to deal with those resources (close the file handle, in 
this case).

Stefan Ram wrote:
> Daniel Moyne <dmoyne@tiscali.fr> writes:
>> I have a class sosaIndex() that takes one parameter sosaRoot ;
> 
>   Declarations of constructors or methods have parameters.
> 
>   Classes do not have parameters (except type parameters).
> 
>   Type names should start with uppercase letters.
> 
>> in this class I have a contructor (method sosaIndex) that on
> 
>   Constructors are not methods.
> 
>> instanciation calls a method setIndexation based on sosaRoot.
> 
>   Method calls do not have »bases«.
> 
>   You might have intended to the /target object/
>   of a method invocation.
> 
>> When the first time I instancie to create an object called "aa" I have
>> this :
>> sosaIndex aa=sosaIndex(sosaRoot);
> 
>   To create objects, one usually uses an instance creation
>   expression, which looks like »new CLASS(...)«
> 
>> but Java does not say anything wrong if I do again :
>> (2) sosaIndex aa=sosaIndex(sosaRoot);
>> I mean instancie a new object with the SAME NAME "aa".
> 
>   An local identifier can be declared only once within
>   a block. But the same identifier might be declared
>   in another block or other scope.
> 
>> Anything wrong with method (2) and what happens to the first
>> instanciation "aa" ?
> 
>   If they have different scopes, they will not disturbe
>   each other.

To the OP:

It will help you and us if you post a simple, short, complete, compilable 
example (my version of SSCCE - not the official expansion :) ) illustrating 
your question and the consequences you wish to discuss.

Your simple, short example should use simple, short indentation based on 2, 3 
or 4 spaces per level, depending on your favorite standard of readability. 
Usenet doesn't like wide lines - keep them to roughly 72 characters (some say 
even lower) maximum.

Be sure to incorporate Stefan's comments into it - no sense in wasting good 
advice.

-- 
Lew

On Fri, 28 Dec 2007 20:51:18 +0100, Daniel Moyne <dmoyne@tiscali.fr>
wrote, quoted or indirectly quoted someone who said :

>I have a class sosaIndex() that takes one parameter sosaRoot ; 

I think you mean sosaIndex is a constructor with one parameter.

In that case it must start with a capital letter.

See http://mindprod.com/jgloss/codingconventions.html

It is best to quote code, rather that English describing code. It is
ever so much less ambigious. 

See http://mindprod.com/jgloss/sscce.html
-- 
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Mark Space wrote:

> Daniel Moyne wrote:
> 
>> Anything wrong with method (2) and what happens to the first
>> instanciation "aa" ?
> 
> Stefan has some good points.  Constructors are not methods.  They
> inherit differently, for example, and it's important to keep these
> differences in mind when designing classes.
> 
> I'm going to answer your question a bit differently than he did. There
> are a couple of different schools of thought when it comes to class
> design.  These schools of thought are not opposite or immiscible but
> rather complementary and both can be used in the same design.
> 
> First is Java Beans.  Real Java Beans (the full spec) are complicated,
> but the basic bean is pretty simple.  You have a default constructor and
> setters and getters which can be called to configure the class.  This is
> a bit like your sosaIndex class.
> 
> Your class:
>    sosaIndex aa = new sosaIndex( sosaRoot );
>    aa.setRoot( sosaRoot2 );
>    aa.setIndexation( sosaRoot2 );
> 
> Bean:
>    JLabel label = new JLabel();
>    label.setText( "Hello World!" );
>    label.invalidate();
> 
> On the other side of the coin there is something called POJO.  POJO
> stands for Plain Old Java Objects.  It's a design technique that
> emphasizes concrete objects which are instantiated completely by their
> constructor and then never touched.  This makes it possible to make
> these objects immutable (a big win in complex designs) and also reduces
> the chances that the programmer will use a series of setters that leave
> the object in an invalid state.
> 
> This means if you want a different object, you do have to make a new
> one.  That's a lot like your second example, where aa gets replaced by
> There's probably a lot more to both sides than this, I'm just hitting
> the basics.
> 
>    aa = new sosaIndex( sosaRoot2 );
> 
> So which is better?  It depends.  If an object is difficult and
> expensive to construct, providing setters and getters might improve
> performance.  Swing objects have a fairly long inheritance tree, so in
> some ways it really does make sense to not construct them if it can be
> avoided.  There are also a myriad of configurations available for the
> average Swing object, which would require a confusing myriad of
> constructors to support if they went the POJO route, so again Beans win
> here by virtue of simplicity.
> 
> OTOH had, most designs are not as complex as Swing, and the overwhelming
> majority of objects in an application should probably be simple POJO
> objects.  KISS.  Keep It Simple Charlie.
> 
> 
> Now on to your second question:  There's no difference between:
>    int aa = 1;
>    // use aa...
>    aa = 2;
> 
> and doing the same for a class reference.  Except as you note a class
> has extra memory associated with it that needs to be disposed of.  When
> the JVM detects that you have removed all references of an object
> (technically it's any "reachable" reference by any thread in the JVM),
> it then will at some point garbage collect that object for you.
> 
> This normally works well, and with out you having to do anything about
> it.  If a class has some other external state associated with it (the
> ubiquitous example is an open file handle) the the finalize() method can
> be over-ridden to deal with those resources (close the file handle, in
> this case).

Mark's and Stefan's answer are detailed enough on my generic question
(actual code would not really help here) for decision help ; both
approaches are possible and acceptable though in my case I think I will go
with :
- the default contructor,
- the setters and getters.

Of course I made a mistake when naming a constructor a method as the latter
one is an entirely different animal.

Following Roedy's advice regarding naming objects I have made a copy of the
very useful URL to comply with coding convention.

Thanks to all people that answered my demand ; I consider this topics as
closed.
 

Daniel Moyne wrote:
> Following Roedy's advice regarding naming objects I have made a copy of the
> very useful URL to comply with coding convention.

Roedy is promulgating the conventions put forth by Sun at about the time Java 
was released to the public, or before.

<http://java.sun.com/docs/codeconv/>

There are others they put out, too, like this one for JSP:
<http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/index.html>
or this general one:
<http://developers.sun.com/software/sundev/whitepapers/java-style.pdf>

-- 
Lew

Lew wrote:

> Daniel Moyne wrote:
>> Following Roedy's advice regarding naming objects I have made a copy of
>> the very useful URL to comply with coding convention.
> 
> Roedy is promulgating the conventions put forth by Sun at about the time
> Java was released to the public, or before.
> 
> <http://java.sun.com/docs/codeconv/>
> 
> There are others they put out, too, like this one for JSP:
>
<http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/index.html>
> or this general one:
> <http://developers.sun.com/software/sundev/whitepapers/java-style.pdf>
> 
Thanks Lew.