java constructor

And once you are inside (an) instance method(s), you can access the fields in 3 ways :

System.out.println(Actor.this.firstName);
	System.out.println(this.lastName);
	System.out.println(good);

Select allOpen in new window

Not sure why you are calling the super constructor - Actor doesn't seem to inherit from anything.

can constructor take argument which is not defined at the top(PhoneNumbersToBeAdded) as instance variable as below but still assigning it to one of intance variable(String[] phoneNumberStored;)


public class Actor {
     

       private String   firstName;
       private String lastName;
       private String good;
       private String[] phoneNumberStored;
      public Actor(String firstName, String lastName, String good, int PhoneNumbersToBeAdded) {
            super();
            firstName = firstName;
            lastName = lastName;
            good = good;
this.phoneNumberStored=new String[PhoneNumbersToBeAdded];

      }


}


I did not understand the meaning
this.phoneNumberStored=new String[PhoneNumbersToBeAdded];


please advice

can constructor take argument which is not defined at the top

Certainly.

I did not understand the meaning...

Well, phoneNumberStored is defined to be a string array. The PhoneNumbersToBeAdded is defined as an integer value, and it is used to establish how large the string array should be. This is why you see a variable of one name being used during the assignment of an instance variable with a different name.

Your code would be ok like that, yes.

>>I did not understand the meaning
this.phoneNumberStored=new String[PhoneNumbersToBeAdded];<<

That's just a declaration. It creates a String array, with PhoneNumbersToBeAdded number of elements.

You'd then have to add the actual String values into the array. (Such as : phoneNumberStored[0] = "1234-567";
phoneNumberStored[1]=  "567-899-9009";
etc., etc.)

Why *are* you calling the super constructor anyway can we know?

oh i think that is not necessary. i just copied code from intetrnet

when to use super()?


and when to use  toString() with constructor like below?

public String toString(){
return "last name: "+this.lastName+" last name:
"+this.firstName;
}

I am corrected. Too much C#   : \

C# will automatically imply "this" when you perform an assignment such as this. I mistakenly carried over that behavior into Java. My mistake.

@mccarl

I didn't say they were identical.

The constructor arguments are only, as you say they are, in that particular case. It is bad practice for them to be used in that way - the params should be discrete, and not confused - mixed up with the fieldnames by duplicating them lexically. The effect would be entirely different if this were the case.

And from what context is a constructor going to be called with the *this* qualifier? Not from a static context (such as main(), I hope) ?

Another side-issue is that the OP has "super()" in the code. Why is this? The implication is - or could be - that at some future time the coder might call a true superclass ctr, and then there would be even more trouble, as a no-arg ctr to a superclass could change the field values again.

Looking at the objects themselves:

public class Actor{
      
      private  static String   firstName="Adam";
      private static String lastName ="Primus";
      private  static String good="Excellent";


      public Actor(String firstName, String lastName, String good) {

     	 super();

	System.out.println("\n1st ctr called");
	System.out.println("==============\n");

	if(firstName==this.firstName){System.out.println("this.firstName and firstName are the same object");}
	else{System.out.println("Not the same object");}

	if(firstName.equals(this.firstName)){System.out.println("this.firstName and firstName hold the same value");}
	else{System.out.println("Not the same value");}

           	 this.firstName = firstName;
           	 this.lastName = lastName;
           	 this.good = good;

	 if(firstName==this.firstName){System.out.println("this.firstName and firstName are the same object");}
	else{System.out.println("Not the same object");}

	if(firstName.equals(this.firstName)){System.out.println("this.firstName and firstName hold the same value");}
	else{System.out.println("Not the same value");}

	firstName = this.firstName;
           	lastName = this.lastName;
           	good = this.good;

	if(firstName==this.firstName){System.out.println("this.firstName and firstName are the same object");}
	else{System.out.println("Not the same object");}

	if(firstName.equals(this.firstName)){System.out.println("this.firstName and firstName hold the same value");}
	else{System.out.println("Not the same value");}

	//reset the vars to the params that were passed in

	 firstName = firstName;
           	 lastName = lastName;
           	 good = good;

	if(firstName==this.firstName){System.out.println("this.firstName and firstName are the same object");}
	else{System.out.println("Not the same object");}

	if(firstName.equals(this.firstName)){System.out.println("this.firstName and firstName hold the same value");}
	else{System.out.println("Not the same value");}

	
	showMe();
      }


    public Actor(String fiName, String laName, String goo,int i) {

	 super();

	System.out.println("\n2nd ctr called");      
	System.out.println("==============\n");

	//reset the fields to the initial assignment strings

	 this.firstName="Adam";
      	 this.lastName ="Primus";
      	 this.good="Excellent";

	if(firstName==this.firstName){System.out.println("this.firstName and firstName are the same object");}
	else{System.out.println("Not the same object");}

	if(firstName.equals(this.firstName)){System.out.println("this.firstName and firstName hold the same value");}
	else{System.out.println("Not the same value");}

	 //now try to reset the fields to the private objects if at all possible

	 this.firstName=this.firstName;
      	 this.lastName =this.lastName;
      	 this.good=this.good;
	

	if(firstName==this.firstName){System.out.println("this.firstName and firstName are the same object");}
	else{System.out.println("Not the same object");}

	if(firstName.equals(this.firstName)){System.out.println("this.firstName and firstName hold the same value");}
	else{System.out.println("Not the same value");}

	 this.firstName="Adam";
      	 this.lastName ="Primus";
      	 this.good="Excellent";

	if(firstName==this.firstName){System.out.println("this.firstName and firstName are the same object");}
	else{System.out.println("Not the same object");}

	if(firstName.equals(this.firstName)){System.out.println("this.firstName and firstName hold the same value");}
	else{System.out.println("Not the same value");}

                 this.firstName = fiName;
                 this.lastName = laName;
                 this.good = goo;

	if(firstName==this.firstName){System.out.println("this.firstName and firstName are the same object");}
	else{System.out.println("Not the same object");}

	if(firstName.equals(this.firstName)){System.out.println("this.firstName and firstName hold the same value");}
	else{System.out.println("Not the same value");}

	   
	showMe();
      }



public static void main(String[] args){

Actor a = new Actor("Me","Myself","I",2);
Actor b = new Actor(firstName,lastName,good);




}


private void showMe(){

	System.out.println(firstName);
	System.out.println(lastName);
	System.out.println(good);	

	System.out.println(this.firstName);
	System.out.println(this.lastName);
	System.out.println(this.good);
	
}

}

Select allOpen in new window

...remembering that lines 118 and 119 can be swapped around for a completely different result.

public class Actor {
     

       private String   firstName;
       private String lastName;
       private String good;
       private Phone[] phoneNumberStored;
      public Actor(String firstName, String lastName, String good, int PhoneNumbersToBeAdded) {
            super();
            firstName = firstName;
            lastName = lastName;
            good = good;
this.phoneNumberStored=new String[PhoneNumbersToBeAdded];

      }


}

Can the array point to one other object called phone which looks similar to below

public class Phone {
      public int phoneNumber;
      public int numberOfSlots;
      public boolean workingOrNonwoking;
      public Phone() {
            super();
            // TODO Auto-generated constructor stub
      }
      public Phone(int phoneNumber,int numberOfSlots, boolean workingOrNonwoking){
            super();
            this.phoneNumber = phoneNumber;
            this.numberOfSlots = numberOfSlots;
            this.workingOrNonwoking = workingOrNonwoking;
      }
      
      public static void main(String[] args) {
            Actor actor=new Actor("hilton", 200);
            Phone phone1=new Phone(101, 1, true);
            Phone phone2=new Phone(102, 1, true);
            Phone phone3=new Phone(103, 1, true);
            Phone phone4=new Phone(104, 1, true);
            hotel.addPhone(room1);
            hotel.addPhone(room2);
            hotel.addPhone(room3);
            hotel.addPhone(room4);
            hotel.addPhone(room5);
            
            
      }
}

Please advice

The code i posted in above comment has some typos. Here is the correct code i intended to post

public class Phone {
	public int phoneNumber;
	public int numberOfSlots;
	public boolean workingOrNonwoking;
	public Phone() {
		super();
		// TODO Auto-generated constructor stub
	}
	public Phone(int phoneNumber,int numberOfSlots, boolean workingOrNonwoking){
		super();
		this.phoneNumber = phoneNumber;
		this.numberOfSlots = numberOfSlots;
		this.workingOrNonwoking = workingOrNonwoking;
	}
	
	public static void main(String[] args) {
		Actor actor=new Actor("hilton", 200);
		Phone phone1=new Phone(101, 1, true);
		Phone phone2=new Phone(102, 1, true);
		Phone phone3=new Phone(103, 1, true);
		Phone phone4=new Phone(104, 1, true);
		Actor.addPhone(phone1);
		Actor.addPhone(phone2);
		Actor.addPhone(phone3);
		Actor.addPhone(phone4);
		Actor.addPhone(phone5);
		
		
	}
}

Select allOpen in new window

Actor.java alooks as below
public class Actor {
     

       private String   firstName;
       private String lastName;
       private String good;
       private Phone[] phoneNumberStored;
      public Actor(String firstName, String lastName, String good, int PhoneNumbersToBeAdded) {
            super();
            firstName = firstName;
            lastName = lastName;
            good = good;
this.phoneNumberStored=new String[PhoneNumbersToBeAdded];

      }


}




I ran the code and got below out put

Original values are Private FirstName Private LastName Private Good
2nd ctr called
Me
Myself
I
Me
Myself
I
1st ctr called
Me
Myself
I
Me
Myself
I



How output with Static variables is different from non static variables. please advice

The Question here is getting pretty messy. I don't think we - I for one - would be happy to move on to dealing with new sub-questions before the main points have been settled, and preferably this question closed. The further a question is extended, the further away from the original point it gets.

What I posted is just illustrational. As usual. It is meant to show what the JVM believes are the values of the 3 String fields in question. And for me the question pauses at this point; because where does anyone think that line 119 in my code above gets the values for those 3 fields from, *if not* the private declarations and assignments at the top of the class???

@krakatoa,

@mccarl

I didn't say they were identical.

No, and I didn't say that you did, sorry if my post was taken the wrong way. The point of my post was that the question had moved on past the original intent of the question without anyone (the experts collectively) correctly addressing that original question.

It is bad practice for them to be used in that way - the params should be discrete, and not confused - mixed up with the fieldnames by duplicating them lexically

Well "bad practice" is, I think, a fairly subjective term and different people would have different views on this. I for one think it is ok to have these variable have the same name, and just access the "hidden" instance variables via the "this" keyword. I am not saying anything about anyone being right or wrong on this, I am merely saying that that is my take on this. One argument that I would put for this (if we were having a friendly debate), is that the major IDEs that I have used (Eclipse & Netbeans) follow this convention (same name parameters as instance fields in constructors and setters) when you invoke their code generation facilities. Also, having them be the same name makes no doubt as to which parameter value needs to be assigned to which instance field.

And from what context is a constructor going to be called with the *this* qualifier? Not from a static context (such as main(), I hope) ?

I'm not sure what you are saying here. Constructors aren't called with any qualifier, they are called using the new keyword.

Another side-issue is that the OP has "super()" in the code. Why is this?

Firstly, I think that was already addressed, with the OP saying that it was just code copied from the internet. Secondly, there is no issue here at all, and in fact if you were to remove that explicit call to "super()" from the constructor, Java will implicitly call the superclass constructor anyway. I don't understand what you are saying about the no-arg constructor changing the field values? If you mean that the superclass constructor could change field values in the subclass, then that isn't right. The superclass has no access to any field in any subclass.

As for the code that you have posted, can you please further explain what you are trying to illustrate, as it's not self-evident from the code. I'm interested to find out what you are demonstrating.



@gudii9,

Can the array point to one other object called phone which looks similar to below

How output with Static variables is different from non static variables. please advice

These questions are very different from the original question that you have asked. Please open new questions if you are interested in getting answers to these.

It's not possible to instantiate using a class' private fields, unless your class extends, or is an inner class. The OP's code doesn't extend, so this question is really a mute point, and academic in the context. Why would a constructor be public, but let you access private fields?? You can't, unless it's an inside job.

So this code, as far as I can see, is demonstrating how the private fields - whether using "this.", or not, are the same things object-internally.

class Outer{

private String firstName ="Noam";
private String lastName ="Chomsky";

public Outer(String firstName, String lastName){

System.out.println("\nMaking inner class with new unique Strings: \"Charles\" \"Babbage\" but first referencing the enclosing class' \"plain\" private members, and then via \"this.\"\n ");
new Inner("Charles","Babbage");

System.out.println("\nMaking inner class with parent's \"non-this-referenced\", private fields, but also showing the values passed in from the parent's main() method ctr call: \n");
new Inner(firstName,lastName);

System.out.println("\nMaking inner class with parent's \"this.-referenced\", private fields: \n");
new Inner(this.firstName,this.lastName);

}


class Inner {

	public Inner(String a, String b){

		System.out.println(firstName+" "+lastName);
		
		System.out.println(Outer.this.firstName+" "+Outer.this.lastName);
		
		System.out.println(a+" "+b);
	}

}

public static void main(String[] args){

	Outer a = new Outer("Ada","Lovelace");

	Outer b = new Outer(a.firstName,a.lastName);

	
} 

}

Select allOpen in new window

Conclusion? :

When your class is instantiated by another class, the args you pass in *can* be assigned to the private fields' values. This, I believe, is what mccarl is saying. BUT, in the context of this question, and only in this context, it doesn't work like that : the vanilla terms and the this. terms are one in the same.

@gudii9:

For the benefit of all concerned in this question, can you say you are happy with the differences between "this.member" and just "member" when referring to a field?

For example, when would you say that "this.member" is going to be the same as "member", both in terms of the object, and in terms of the value it holds?

For the benefit of all concerned in this question, can you say you are happy with the differences between "this.member" and just "member" when referring to a field?

Yes I am happy and i will prefer using this.member as I tend to store the instance vaiables via the method parameter values most of the time for the object

One other question for you -

would you in future rather do this :

public class Actor {
      

       private String   firstName;
       private String lastName;
       private String good;
      public Actor(String fName, String lName, String ability) {
            super();
            this.firstName = fName;
            this.lastName = lName;
            this.good = ability;
      }


}

Select allOpen in new window

or would you still stick to the original :

public class Actor {
      

       private String   firstName;
       private String lastName;
       private String good;
      public Actor(String firstName, String lastName, String good) {
            super();
            this.firstName = firstName;
            this.lastName = lastName;
            this.good = good;
      }


}

Select allOpen in new window

Just a question. ;)

I prefer below as distinguishing names

public class Actor {
     

       private String   firstName;
       private String lastName;
       private String good;
      public Actor(String fName, String lName, String ability) {
            super();
            this.firstName = fName;
            this.lastName = lName;
            this.good = ability;
      }


}


But IDEs are forcing below

public class Actor {
     

       private String   firstName;
       private String lastName;
       private String good;
      public Actor(String firstName, String lastName, String good) {
            super();
            this.firstName = firstName;
            this.lastName = lastName;
            this.good = good;
      }


}
   

So either is fine with me

>But IDEs are forcing below<

Right. . .

This, I believe, is what mccarl is saying. BUT, in the context of this question, and only in this context, it doesn't work like that : the vanilla terms and the this. terms are one in the same.

This is still all wrong. The point of this question is that they AREN't the same... 'this.firstName' refers to the private field and 'firstName' refers to the parameter that has been passed in... ie. two different things.

I think the point here is still being missed. Talking about private/public, static/non-static, classes that extend others or contains other are confusing the issue. The simple point to this question is that you have two different variables that have the same name... a field called 'firstName' and a method parameter called 'firstName'. Because they are the same name, the method parameter effectively hides the field value, and so to refer to the field value it must be qualified as 'this.firstName'

Yes, by changing the name of the parameter variables, the field variables are no longer 'hidden' as they were before, as so in this case the 'this.' qualifier would not be needed. And while that is some peoples preference, it isn't mine; for two reasons one of which has already been mentioned, that IDE's don't do it that way. The second reason being that, as your example above shows, there is nothing obvious that tells you that the 'abillity' parameter value is what should be assigned to the 'good' field. Now I realise that not always would the names be THAT different, but it still can leave room for error.

This is still all wrong. The point of this question is that they AREN't the same... 'this.firstName' refers to the private field and 'firstName' refers to the parameter that has been passed in... ie. two different things.

You have COMPLETELY missed the meta here!

Yes,  Java itself distinguishes between passed-in args and the local variables - but this only valid when those args come from another class. If you run the code I have posted, you will see that a local constructor - such as via an inner class - will resolve "this.member" vars to the same values and objects as plain "member" vars, IF the passed in args are **lexically** identical to the (private) members.  The fact that things can be coded like this at all - and especially in a knowledge forum like EE - means that if the programmer is unaware of this behaviour being different in the two cases, that he will sooner or later run into trouble.  If for some reason, you have to code an Inner class, and you do not realise that the varargs passed to the constructor - if **lexically identical** to the Outer's private fields - will operate on those private fields, you will be sadly off the mark. You don't seem to see this, although I've posted reams of code to show how it works. Did you run any of it?

And I have to say that this comment snip from you seems to prove that you don't see the point I am trying to make :

And while that is some peoples preference, it isn't mine;

because if you coded the other way 'round, you'd never be in danger of passing the wrong values, and you'd never need to make use of "this.". (Unless and until you ever needed to code :  "some_member_var = this.some_m_var" (where some_member_var is the passed-in arg, and some_m_var the local one).

I've been asked to comment on this by the author so my comment is this (no pun intended): as always when Java coding (or any kind of coding) adhere to best practice (see some Java 'style guides') and learn by imitating the practices and styles of the best exponents of the craft. Best practice is the following in a ctor

public Foo (String bar) {
   this.bar = bar;
}

Select allOpen in new window

There is no good reason to invent different names for parameters and since you're not doing so, this. IS an essential qualifier.

I think the puzzlement is in some sense surrounding why one would want to create a private String with an associated value to begin with, only to change it in the constructor?

Well the only time such a thing would be done is to provide a default value if there were also a parameterless ctor

>> if there were a parameterless ctor<<

. . . which is not the case in this question of course.

Making it surely preferable - in this case (given the private String assignments) - to make those into

private final String firstName, lastName, good.

And it's worth remembering that calling the constructor with different literal parameters rather than lexically identical ones to the private members, means you are not precluded from doing this :


public Outer(String fiName, String laName){

       String firstName = "John";
       String lastName = "Doe";
}


whereas doing this would be impossible :

public Outer(String firstName, String lastName){

      String firstName = "John";
       String lastName = "Doe";

}

(I'm not saying that the former is a 'good idea' nor even that I can think of a scenario wherein you would ever want to, but simply that this is the effect of how Java works).


----------

I have also read mccarl's attention request, wherein I am accused of "taking the thread off in some random direction". The only thing that is random, is a comment like that, since I am demonstrating what different effects it may have using the parameters under certain -even other conditions.

Try to remember, mccarl, that the code runs according to how the JVM interprets it, and not that I have somehow been able write a trojan JVM that only does my bidding.

For the nth time, the question IS simple. It specifies two snippets of code, that are only different by the using of this to access the private member fields. And then poses this simple question...

If i do not give this inside the contructor how it is different

A simple question with a very simple answer that I provided above. Now, I have no problem with comments that are making additional points that are closely related to the original question, but the reason for the RA was because the vast majority of comments here were NOT closely related to the original question, and one of those unrelated comments was accepted an the answer to the original question. Some, I agree, are technically correct points but that doesn't make them related to the question. It would be like me saying, "oh by the way, make sure that you keep those semicolons on the end of each statement". This is a technically correct point to make, but has nothing to do with the original question.

The only thing that is random, is a comment like that

It's not random at all, apart from all the previous off-topic posts that I have identified, let me describe what my issue is with the more recent off-topic posts...

I think the puzzlement is in some sense surrounding why one would want to create a private String with an associated value to begin with, only to change it in the constructor

There is no "puzzlement" here because in the original question, the author is NOT "creating a private String with an associated value". The private String's are not initialised to any initial value, so (presumably) the constructor might be the only way to set them to a value.

Making it surely preferable - in this case (given the private String assignments) - to make those into

 private final String firstName, lastName, good

Again, a possibly valid point to make (assuming that it IS the intention of the author of this code for those fields to be immutable) but still has nothing to do with using this to access those private fields when those fields have been hidden by the constructor parameters.

public Outer(String firstName, String lastName){
       String firstName = "John";
        String lastName = "Doe";
 }

Yet again, a technically correct point that you can't create local variables with the same name as method/constructor parameters. But, yet again, what does this have to do with the original question?

Try to remember, mccarl, that the code runs according to how the JVM interprets it, and not that I have somehow been able write a trojan JVM that only does my bidding.

What????

"this." is simply a shorthand (reference?) to the current object. If it weren't there, you, as the coder, would need to point at the object you want, verbatim, each time.

If "this" wasn't available in Java, then there are certain contexts where it would be much harder/impossible to do what you intended to do, ie. you would have to actually pass "the object you want" into a method on an object for it to be able to reference itself, or in the case of code within a constructor you would have absolutely NO way to reference the object being created.

the author is NOT "creating a private String with an associated value

This I recognise. I should not have brought this into the discussion. (I was trying to get at another point I was making across, but didn't make the reference back to my point correctly, and so it looked like it related to the actual OP code. So agreed, we can leave this situation out).

I am writing a comment about your other points however, and will post as soon as I can.

Yet again, a technically correct point that you can't create local variables with the same name as method/constructor parameters.

You managed to throw the baby out with the bathwater here completely already. This ISN'T what I was illustrating at all; you CAN create "local" variables with the same name. Look at this snip :

class Thing {

  private String name = "Me";

  public Thing(){

	super(); // ("don't ask me" why I'm here)

	String name = "You"; // - if you want to Sys out the two "name"s, they will be different.

	}
}

Select allOpen in new window

. . . because the ctor-local "name" field is different from the class' field, even though they are lexically identical.

But the following will NOT work, (you won't be able to even compile), precisely because of the inverse of the above statement, inasmuch as you are already declaring a local String 'name' field in the ctor args, and trying to create it again in the ctor body (which won't work) :

class Thing {

private String name = "Me";

public Thing(String name){

super();

String name = "You";

}}

Select allOpen in new window

 to wit:

 [Thing.java:9: error: variable name is already defined in constructor Thing(Strin
g)
String name = "You";
       ^
1 error]

What you MIGHT have meant, and which I have been labouring to point out, is that you cannot declare two vars with lexically the same names within the same scope. The ctor argument IS a local declaration, AND SO IS the attempted declaration of "name" AGAIN inside the ctor body : BUT THIS WILL NOT WORK, because they are LEXICALLY IDENTICAL.

**HOWEVER**, the moment you do this :

class Thing {

private String name = "Me";

public Thing(String name2){

super();

String name = "You";
//name = "You";

System.out.println(this.name);
System.out.println(name);
System.out.println(name2);

}

public static void main(String[] args){

new Thing("Tom");

}

}

Select allOpen in new window

you have THREE fields attempting some form of association- a "this.name", a "name" in the ctor body, and a lexically different member set up for the passed-in value.


. . . and if you change the above lines :

String name = "You";
//name = "You";

to

//String name = "You";
name = "You";

. . .  then you of course change the this. member name field.

If "this" wasn't available in Java, then there are certain contexts where it would be much harder/impossible to do what you intended to do, ie. you would have to actually pass "the object you want" into a method on an object for it to be able to reference itself,

That's right. And that's exactly what the statement from me that you quote is saying.

or in the case of code within a constructor you would have absolutely NO way to reference the object being created.

This isn't right however. And I can't see why you would need to. But in any case, as you keep insisting, this is a digression. So let's not go there.

(PS. The behaviour concerning the relationship between lexically identical variables, used to be - and maybe still is - referred to as "fall-through"; meaning the original reference is used unless it is overridden locally and accessed locally, i.e. in its scope).

(And before we revolve back to the question of me using hard-wired values for the private Strings here, this is only to illustrate that the values are different, instead of trying to compare anything that's passed in with an unhelpful 'null' value.)

mccarl - you said in your comment - for which you obtained points -, that the two styles are completely different, and that the "this" was not optional. This is completely incorrect, for the reason I have just given in my last 'footnote' above. And it shows why kaufmed's original answer stands up.