Re: [Class]Ridiculous question

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.

.

Relevant Pages

  • Re: Class in another file
    ... > oriented design is that it is a technique that focuses design on ... programmer did was: design a way of using a structure of standard ... different but related object (i.e. what's now called a "constructor ... that's not as nice as true parameter overloading that Common Lisp ...
    (comp.lang.java.programmer)
  • Re: C++ design question
    ... > Why not invoke the barDerived constructor? ... which addresses design issues rather ... barDerived1, fooDerived2 with corresponding barDerived2, fooDerivedN ... a burden on developers of the various fooDerivedN. ...
    (comp.object)
  • Re: Use the accessor! Was: Copy Constructor Usage
    ... I think you are getting too hung up on the copy constructor bit. ... accessor fns on some bogus efficiency argument. ... a field 'leng' might map onto an accessor 'size'; ... No style or design rules give us a free lunch. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: initializing mutable class attributes
    ... I need to understand the 'WHY' behind a design ... satisfied with an explanation of "that's the Python way and you just have to ... the design of a language can make a very good language. ... default constructor and a non-default one at the same time. ...
    (comp.lang.python)
  • Design Questions re Subclassing
    ... If Range should subclass TreeSet as I suspect, I'm not sure if Range should ... I'm not sure if I can do everything in one well-written Range class or if I ... constructor to the Range. ... I'm trying to figure out if I have a fundamental design flaw here or if I've ...
    (comp.lang.java.programmer)