I think the book forgot to explain this: two of the same method?

Code:

---

    public static final String DEFAULT_COLOR = "white";
    public String name;
    public boolean running;
    public String color;
    public int numMiles;

  [COLOR="Red"]  public Automobile() {[/COLOR]
        this(false, DEFAULT_COLOR, 0);
    }

    [COLOR="Red"]public Automobile(boolean running, String color, int numMiles) {[/COLOR]
        this.running = running;
        this.color = color;
        this.numMiles = numMiles;
        name = null;
    }

---

I am currently studying methods and objects. This was part of the code from the book "Java Programming For The Absolute Beginner". I just missed out on understanding this code though.

1) Can you explain this(false, DEFAULT_COLOR, 0);. Does "this" just take over any method that is the same as the class name?

2) Why are there 2 public Automobile methods made in this class Automobile? It seems that the code above "this(false, DEFAULT_COLOR, 0);" would interfere with its current method.

3) Wouldn't it have been better to just do this instead of adding two Automobile methods? Wouldn't that do the same thing?

Code:

---

    public String name = null;
    public boolean running = false;
    public String color = "white;
    public int numMiles = 0;

---

Those aren't methods but rather constructors, and this as the first call in a constructor calls another constructor, much like super calls the super constructor.

Also look up "method overloading". A class can have several methods or constructors with the same name but which take different arguments, and will know which one to call by what is passed to it.

Quote:

---

Originally Posted by Fubarable

Those aren't methods but rather constructors, and this as the first call in a constructor calls another constructor, much like super calls the super constructor.

---

So would #3 have basically done the same thing? When would you have needed to make a constructor do this when the variables in the current class are declared for all instances anyway.

Is it possible to see an example that might be more practical then this?

Quote:

---

Originally Posted by Iron Lion

Also look up "method overloading". A class can have several methods or constructors with the same name but which take different arguments, and will know which one to call by what is passed to it.

---

Interesting enough, I just got through a few more pages and "method overloading" is the current topic. I think this is great. I was wondering how you have a method take in multiple data types. Kinda like println() method, it takes all sorts.

Quote:

---

Originally Posted by AcousticBruce

Is it possible to see an example that might be more practical then this?

---

what do you expect? if somebody instantiate an object with new Automobile() the fields running will be false, the color will be white and the numMiles will be 0. but, if somebody instantiate an object with new Automobile(true, "red", 10000) the fields of this object will be set to the arguments in the constructor. practical enough?

Quote:

---

Originally Posted by j2me64

what do you expect? if somebody instantiate an object with new Automobile() the fields running will be false, the color will be white and the numMiles will be 0. but, if somebody instantiate an object with new Automobile(true, "red", 10000) the fields of this object will be set to the arguments in the constructor. practical enough?

---

The vars are already initiated at the beginning of the class and the values could have been placed there and the outcome would be the same.
Is there really a need of a constructor?

The only thing the constructor does is change values of already initialized vars ( am I right?)
Is this just a matter of preference or is there a need to make a constructor like this?

So I was asking for a more practical section of code that might help. It just kinda seems you are annoyed with my question.

Just so all of you that kindly helped me understand where my concern was, I ended up finding out something interesting that made it all make sense.

If you do NOT create any constructor methods, then the compiler will make one for you, WITHOUT arguments.
If you DO define, any number of, constructor methods with arguments, the compiler will NOT make one.

So you would have to make a constructor method without arguments or just make none at all to use this code below.

Code:

---

Automobile car1 = new Automobile();

---

This is why I thought it was redundant to create a constructor method without arguments.



But I tried something. I deleted the top line in the code below shown in red (the constructor without arguments) and I could no longer create and Automobile() object without arguments like the code above. Very interesting.

Code:

---

[COLOR="Red"]public Automobile() {
        this(false, DEFAULT_COLOR, 0);
    } [/COLOR]

    public Automobile(boolean running, String color, int numMiles) {
        this.running = running;
        this.color = color;
        this.numMiles = numMiles;
        name = null;
    }

---

You got to give us Newbs a break :D . This stuff is pretty confusing sometimes. But the nice thing is there is always a logical reason for this stuff, and when I do not see the logic, I come back to this forum to haunt you all ;)

Quote:

---

Originally Posted by AcousticBruce

Just so all of you that kindly helped me understand where my concern was, I ended up finding out something interesting that made it all make sense.

If you do NOT create any constructor methods, then the compiler will make one for you, WITHOUT arguments.
If you DO define, any number of, constructor methods with arguments, the compiler will NOT make one.

So you would have to make a constructor method without arguments or just make none at all to use this code below.

Code:

---

Automobile car1 = new Automobile();

---

This is why I thought it was redundant to create a constructor method without arguments.

---

There's also another little side effect: if you only define one constructor with arguments you can only create such an object with arguments. It is of no use if you initialize the member variables because they get overwritten by the constructor. Even if you don't have any sensible arguments you have to supply them (because you only have a constructor that takes arguments).

Defining a no-arg constructor can come in handy if your member variables can take sensible default values (e.g. a white car, no miles yet). Of course that no-arg constructor can call the other constructor (the one that does take arguments) with those default member variable values and let the other constructor do the job.

As a 'corollary': it is of no use to initialize member variables that are always set by the constructor(s).

kind regards,

Jos

Jos has already explained about the no-arg constructor only being created if you haven't declared another constructor, but there's a design reason for using the above style that you are questioning.

What if there is some processing to be done to the data passed into the second (main) constructor? What if, instead of assigning the values straight, there is some logic that also populates other fields (value of car possibly?) based on these. Now, you don't want to be writing that into both constructors, so you pass the defaults down through to the main constructor that handles all the data.

Of course, you might say that the Autmobile class doesn't do that. To which I would reply, quite correct...at the moment. But requirements change, and clients are notoriously fickle.