CODEWITHSUNDEEP
java
TKoL
TKoL

Reputation: 13892

Best Practices -- Constructors and Setters

I have an IDE which I can use to automatically create constructors and setters for instance variables, but I was wondering if the way that it creates them is possibly not best practice. Here is what it does:

private String partNum;
private String partDesc;
private int quant;
private double price;

public Invoice( String partNum, String partDesc, int quant, double price )
{
    this.partNum = partNum;
    this.partDesc = partDesc;
    this.quant = quant;
    this.price = price;
}

It's the 'this.name' thing that I'm worried about, as well as the constructor labeling the parameters the same names as the variables it's constructing. The setter also does the same thing -- uses a parameter name that's the same as the name of the variable it's setting, and uses this.name.

So, is there anything wrong with this?

Upvotes: 0

Views: 1293

Answers (4)

Heisenbug
Heisenbug

Reputation: 39164

No there's nothing wrong. The this keyword resolve the ambiguity because it tells the compiler that the l-value you are setting is the member variable(es. this.partNum) and not the input parameter(partNum).

If this is a bad practice, that's more a matter of personal taste. Some people don't like to use the same name for both the member variable and the input parameter. Personally I've use this often for several reasons:

  • avoid proliferating of names
  • Eclipse start autocompleting the name if it starts with "this." :)

Upvotes: 1

Perception
Perception

Reputation: 80593

What you are witnessing is pretty standard Java practice, and is even mentioned in the Java Language Specification:

If a name declared as a local variable is already declared as a field name, then that outer declaration is shadowed (§6.3.1) throughout the scope of the local variable. Similarly, if a name is already declared as a variable or parameter name, then that outer declaration is shadowed throughout the scope of the local variable (provided that the shadowing does not cause a compile-time error under the rules of §14.4.2). The shadowed name can sometimes be accessed using an appropriately qualified name.

For example, the keyword this can be used to access a shadowed field x, using the form this.x. Indeed, this idiom typically appears in constructors (§8.8):

class Pair {
        Object first, second;
        public Pair(Object first, Object second) {
                this.first = first;
                this.second = second;
        }
}

In this example, the constructor takes parameters having the same names as the fields to be initialized. This is simpler than having to invent different names for the parameters and is not too confusing in this stylized context. In general, however, it is considered poor style to have local variables with the same names as fields.

When local variables to a method have the same name as class variables, they effectively 'shadow' or hide those variables. But you can still access the class variables by referring to them via the this context scope.

Upvotes: 1

sr01853
sr01853

Reputation: 6121

No. that is not at all a problem. These are just variable names. The lvalue and rvalue are going to maintain their uniqueness.

Upvotes: 1

mac10688
mac10688

Reputation: 2205

That is my preferred way. Otherwise, you would have to think of different arbitrary names for the input parameters and that turns into a hassle.

Upvotes: 3

Related Questions