Overloaded constructors and this()

[Paul Berry]

Hello everyone!

I'm reading Java Head First (pg 256), and am not understanding the stated use of this() for overloaded constructors. The scenario is that you have overloaded constructors that "all do the same thing", except they handle different argument types. So the use is to put a call to this() in all but one constructor and then put all the code in the 'real' constructor so you don't have to maintain the same code in multiple constructors. Ok, so............

I thought there might be some minor code in each constructor which 'massages' the parameters so they fit into the one main constructor then you call it with this(args). However since this() has to be the first thing in the constructor, I'm not seeing how that scheme is useful at all. I seem to be completely missing the point. Can I get some clarification?

Thank you,
Paul

[Paul Clapham]

Wasn't there an example to go with that? I'm surprised to hear that. Anyway...

public class Example {
  private String value;
  private boolean init;
  public Example() {
    init = true;
  }
  public Example(String input) {
    this();
    value = input;
  }
  public Example(int input) {
    this();
    value = Integer.toString(input);
  }
}

[Campbell Ritchie]

All constructors do the same thing (or at least they ought to): getting the object into a consistent state (or establishing up its invariants). Imagine you have several constructors which all set up the object's invariants, but take different numbers of arguments, and fills in the gaps with default values. You can avoid duplicated code by the use of this(). Like "this":

public class Clock extends Instrument
{
   private int hours;
   private int minutes;
   private int seconds;

/**
 * Sets up a Clock object with a default time of 00:00:00
 */
   public Clock()
   {
      this(0);
   }

/*
 * Sets up a Clock object with the hours, assuming it is that many hours o'clock precisely
 *@param hours The hour to be shown
 */
   public Clock(int hours)
   {
      this(hours, 0);
   }

/*
 * Sets up a Clock object with the hours and minutes, assuming that time is exact
 *@param hours The hour to be shown
 *@param minutes The minute to be shown
 */
   public Clock(int hours, int minutes)
   {
      this(hours, minutes, 0);
   }

/*
 * Sets up a Clock object with the hours and minutes and seconds
 *@param hours The hour to be shown
 *@param minutes The minute to be shown
 *@param seconds The second to be shown
 */
   public Clock(int hours, int minutes, int seconds)
   {
      super("Clock");
      this.hours = hours;
      this.minutes = minutes;
      this.seconds = seconds;
   }

/* lots more methods */
}

As you see, this saves you writing seconds = 0; thrice, which might have been a maintenance pitfall. The path of control from all four constructors ends up at the 3-arguments constructor, where the assignments are carried out.
You can tell the Instrument class has a constructor which takes one String argument, eg "Clock", "Ammeter", or "Micrometer".

[Paul Berry]

Thanks for the replies!

OK, I can see how several different argument types can be handled, but....

What if the argument is not exactly what it needs to be (like an int instead of a float), or some other sort of manipulation/decision needs to happen *before* passing it down the line to another constructor? How would I have code that processes the arguments passed *before* calling this() ?

It seems that there is a deliberate design to keep that from happening. Is it just bad programming practice (like I should always process arguments before using "new"), or will something really bad happen if I could have code before "this()" ?

[Campbell Ritchie]

Beware of different types for constructors. If your field is a float (well, a double would probably be better), you can get away with automatic casting, so 123 becomes 123.0f. But for other things, you should be restricting the constructor. Remember the constructor tells users what type of data you requrie for your class, and you shouldn't let people try to squeeze the wrong things in.

[Paul Berry]

I should say that there was an example in the book, but it was short and targeted to make their point and didn't help with my supplimental question.... super() or this() have to be first, but it didn't say why, or address running code prior to.

I get the impression that it would be bad style to put a lot of additional code in each overloaded constructor. Probably a maintenance nightmare to follow a bunch of branches after you call new. Ask for a new instance and just do what is necessary to get that new object instead of branching all over the place during object creation.

Thanks for the help!

[Paul Clapham]

Paul Berry wrote:I should say that there was an example in the book, but it was short and targeted to make their point and didn't help with my supplimental question.... super() or this() have to be first, but it didn't say why, or address running code prior to.

Having worked in languages where the call to the super() constructor didn't have to be the first thing in a constructor, I would say that it was an arbitrary decision made by the designers of Java. No doubt they had a good reason for that decision, but possibly the designers of Object Pascal had a good reason for making a different decision.

Anyway the bottom line is that it's extremely difficult to get any work done before calling this() or super() in Java. It's just something you have to deal with if the requirement arises.