This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

"Shadowing" fields  RSS feed

 
Jinny Morris
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the Java Online Tutorial, in the section entitled "Passing Information to a Method or a Constructor", I read:

A parameter can have the same name as one of the class's fields. If this is the case, the parameter is said to shadow the field. Shadowing fields can make your code difficult to read and is conventionally used only within constructors and methods that set a particular field. For example, consider the following Circle class and its setOrigin method:

public class Circle {
private int x, y, radius;
public void setOrigin(int x, int y) {
...
}
}


Why would you want to do this? Why wouldn't you just use the instance variables?

Thanks!
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 37242
519
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jinny,
If this is a simple setter, the implementation would look like:

There are two schools of thought on the above example. One says it is confusing because you could forget the "this." The other says it is good because the variable names clearly specify that we are dealing with a setter.

If this method has any logic, it is not a simple setter. Then the example is illustrating the confusion of shadowing x and y because the reader has to realize we are not referring to the instance variables.
 
Pravin Jain
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is considered as a good practice and many good corporates have in their
coding standards, to always use this with instance variables.

Anyway shadow variables I believe is the case where a subclass shadows the
instance variable(non-private) from the super class.
 
Jinny Morris
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear Folks -

Thank you to the members who replied, but I guess I wasn't too clear in what I asked -

I know how to "shadow" an instance variable - use the same name as a parameter of a method (usually constructor). So, for example, if one of my instance variables is defined as int fieldVariable, and I then write a method in the same class as classMethod(int fieldVariable){stuff ...), the instance variable is invisible within classMethod because it is "shadowed" by the method parameter. I can only access my instance variable by using a construct such as: this.fieldVariable.

This seems to me to be somewhat convoluted and confusing, because I could just as easily write my method as classMethod(int newFieldVariable){stuff...}

So I am asking if someone can tell me about a situation in which it would be preferable to shadow an instance variable ... ?

Thanks!
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jinny Morris:
So I am asking if someone can tell me about a situation in which it would be preferable to shadow an instance variable ... ?


In the HTML output of javadoc for the method you won't see the member variable name, so it could help to use an identical name, assuming that the name for the member variable is the best name to identify exactly what that variable is holding, rather than come up with a less specific, or potentially confusing different name.

That would probably only have value for methods that take multiple parameters (it would apply to all constructors) since a method taking a single variable could have its name completely identify the variable.

e.g.
setBirthDate(Calendar birthDate)
doesn't buy you much in documentation versus
setBirthDate(Calendar date)

but
setInsuranceData(Calendar dateOfTheAccident, Calendar dateOfClaimApproval, Calendar dateOfClaimPayment)

is better than

setInsuranceData(Calendar accDate, Calendar apprDate, Calendar payDate)

or some other variation where the person writing the code used different names than the member variables because they were looking at
dateOfTheAccident = accDate;
and not the HTML Javadoc output.

-----------------

I have seen a technique where you add an underscore "_" to the variable name to keep essentially the same name, but avoid having to use the "this" keyword.

birthDate = birthDate_;

Similarly, Microsoft in their MFC Class library have a practice of putting m_ (for member data) in front of the member variables. So you avoid "this" with

m_birthDate = birthDate;

The latter technique is not allowed on this site for their Cattle Drive assignments. Not sure about the former.
[ August 14, 2007: Message edited by: Red Smith ]
 
Jinny Morris
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Red - Thanks much! Exactly the kind of thing I was hoping for!
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!