Re: [Class]Ridiculous question
- From: Mark Space <markspace@xxxxxxxxxxxxxx>
- Date: Sat, 29 Dec 2007 00:56:17 GMT
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).
.
- Follow-Ups:
- Re: [Class]Ridiculous question
- From: Daniel Moyne
- Re: [Class]Ridiculous question
- References:
- [Class]Ridiculous question
- From: Daniel Moyne
- [Class]Ridiculous question
- Prev by Date: Re: Help with packages getting started
- Next by Date: Re: [Class]Ridiculous question
- Previous by thread: [Class]Ridiculous question
- Next by thread: Re: [Class]Ridiculous question
- Index(es):
Relevant Pages
|
|
