Re: [Class]Ridiculous question

Daniel Moyne wrote:


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).