Welcome!

Java Authors: Kira Makagon, Dana Gardner, Carmen Gonzalez, Brian Vandegrift, Pat Romanski

Related Topics: Java

Java: Article

Java Gotchas: Instance Variables Hiding

Java Gotchas: Instance Variables Hiding

If methods with the same signatures or member variables with the same name exist in ancestor and descendant classes, the Java keyword super allows access members of the ancestor. But what if you do not use the keyword super in the descendant class? In case of methods, this is called method overriding and only the code of the descendant's method will execute. But when both classes have a member variable with the same name, it may cause a confusion and create hard to find bugs.

Recently in one of the Java online forums, a user with id cityart posted a question about a "strange behavior" of his program, and I decided to do some research on this subject.

Let's take a look at the Java program that declares a variable greeting in both super and subclasses (class A and class B). The subclass B also overrides the Object's method toString(). Please note, that the variable obj has a type of the superclass (A), but it points at the instance of the subclass (B), which is perfectly legal.


class A {
   public String greeting ="Hello";
}

class B extends A {
	public String greeting="Good Bye";
	 public String toString(){
		return greeting;
	}
}

public class VariableOverridingTest {
    public static void main(String[] args) {
      A obj = new B();
      obj.greeting="How are you";

      System.out.println(obj.greeting);
      System.out.println(obj.toString());
 }
}

If you compile and run this program, it'll print the following:

How are you
Good Bye

How come? Aren't we printing a member variable greeting of the same instance of the class B? The answer is no. If you run this program in IDE through a debugger, you'll see that there are two separate variables greeting. For example, Eclipse IDE shows these variables as greeting(A) and greeting(B). The first print statement deals with the member variable of the class A since obj has a type A, and the second print uses a method of the instance B that uses its own variable greeting.

Now, change the declaration of the variable obj to


      B obj = new B();

Run the program, and it'll print "How are you" twice.

But since you wanted the variable obj to have the type of the superclass A, you need to find a different solution. In the code below, we prohibit direct access to the variable greeting by making it private and introducing public setter and getter methods in both super and subclasses. Please note that in the following example, we override the setter and getter in the class B. This gives us a better control of which variable greeting to use.


class A {
 private String greeting ="Hello";
 public void setGreeting(String greet){greeting = greet;}
 public String getGreeting(){return greeting;}

}

class B extends A {
	 private String greeting="Good Bye";
	 public String toString(){
		return greeting;
	}
public void setGreeting(String greet){greeting = greet;}
public String getGreeting(){return greeting;}

}

public class VariableOverridingTest2 {
public static void main(String[] args) {
A obj = new B();

obj.setGreeting("How are you");

System.out.println(obj.getGreeting());
System.out.println(obj.toString());

}
}

This example is yet another illustration of how encapsulation may help you to avoid potential errors caused by multiple declarations of member variables with the same name in the inheritance hierarchy. If needed, we still can access the superclass' variable greeting from the class B by using super.getGreeting().

In Sun's Java tutorial, I found only a brief mentioning of member variables inheritance over here: http://java.sun.com/docs/books/tutorial/java/javaOO/subclass.html

Basically, you can hide a variable but override a method of a superclass. Java Language Specification describes hiding of instance variables over here: http://java.sun.com/docs/books/jls/ second_edition/html/classes.doc.html#229119

One more term to be aware of is shadowing. Here's another Sun's article that discusses hiding and shadowing: http://java.sun.com/developer/TechTips/2000/tt1010.html#tip2 What do you think of the following quote from this article: "First an important point needs to be made: just because the Java programming language allows you to do something, it doesn't always mean that it's a desirable thing to do." Well, if a feature is not desirable, why keep it in the language? Most likely, creators of the language decided to keep a separate copy of the superclass' instance variable to give developers a freedom to define their own subclasses without worrying of overriding by accident some internal members of the superclasses. But in my opinion it should be a responsibility of the superclasses to protect their members.

I'd love to see some practical examples, which would show when this feature of the Java language could be useful.

More Stories By Yakov Fain

Yakov Fain is a co-founder of two software companies: Farata Systems and SuranceBay. He authored several technical books and lots of articles on software development. Yakov is Java Champion (https://java-champions.java.net). He leads leads Princeton Java Users Group. Two of Yakov's books will go in print this year: "Enterprise Web Development" (O'Reilly) and "Java For Kids" (No Starch Press).

Comments (11) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Chakra Yadavalli 09/15/04 08:53:53 AM EDT

I guess the author clearly states what the problem is and how the encapsulation helps in avoiding the potential errors. I think the following line from the text of the article would be enough to red flag this for any rational developer. Or, this may make it more noticeable :-)

LOOK AT THE LINE BELOW. POTENTIAL BUG!!!

"This example is yet another illustration of how encapsulation may help you to avoid potential errors caused by multiple declarations of member variables with the same name in the inheritance hierarchy. If needed, we still can access the superclass' variable greeting from the class B by using super.getGreeting()."

And in most scenarios of real software development, we never have the luxury of time to track the "patient zero" who coded this sort of bug and treat him. :-)

As for the existence of debates such as this, THEY SHOULD (I mean MUST) exist for the sake of posterity. The correct solutions to these problems to be aware of such problems. If one thinks that articles such as this are "encouraging" the such "malpractices" (without reading the complete articles) then they are wrong and should be advised to use good commonsense in adopting coding techniques.

F. Libuste 09/15/04 07:53:37 AM EDT

The problem of hiding variables will never arise if you apply good practices of Oriented Object programming and NEVER make use of anything else than "private" as a modifier for class members. And yse accessors when needed.

Now as for method overriding, well...that is *exactly* what OO design is for. Making sure your objects are correctly polymorphic, behave properly and offer the proper services and proper extensibility through their exposed methods.

This whole debate should not exist in the first place, and to me, the article comes from software malpractice, and is not depicted as such, which is not so good IMHO. Correct OO design is the issue that should be addressed here, not the effects of it.

Chakra Yadavalli 09/14/04 11:07:46 AM EDT

Good pitfall. This is quite common and very had to find if you have more than two classes in the inheritance tree and the instance members are "protected" which is very common thing that we see. If we go by Bertrand Myer's Object Oriented software construction, which enforces strict encapsulation by saying no to protected variables, we will *not* run in to these sort of problems. But then again, we may be tempted to write "Train Wreck" code -- obj.getThis().getThat().getSomething()

There is another pitfall that has the disguise of this "overridding." Guess what is printed by the following code?

public class A {
public static void getInstance(){
System.out.println("class A");
}
}

public class B extends A {
public static void getInstance(){
System.out.println("class B");
}
}

public class Tester {
public staic void main(Strnig[] args) {
A obj = new B();
obj.getInstance();
}
}

This would print "class A" because, the static methods go by the name "class methods" in Java. In C++, similar code would print "class B". Java language says, static/class methods are not inherited and cannot be overriden. But allowing to define classes with the same name, though legal when looked from the namespace perspective, would result in these pitfalls. The irony with these "false" static methods AKA class methods is that, it makes your brain hurt when you look at code like the one below... Keeps you guessing why it does not throw NullPointerException.

A obj = null;
obj.getInstance();

These are the many good reasons why one should enforce, with the help of IDEs like Eclipse, the practice of qualifying instance members with "this", "super" and static members with the "type name".

Sebastian Tyrrell 09/14/04 10:39:38 AM EDT

Both David Hibbs and J.R. Titko are right that there is no problem if the design is right - in particular if you have proper encapsulation (i.e. keep the data member private and use getter and setter functions). But I still can't imagine a single legitimate usage. The closest I can come is that it means that you don't need to worry what (private) data members base classes might have, and can reuse their names for your own purposes. I think this is what David means when he says "... the capability to do this is required or else behaviours of parent classes are not encapsulated ...". I'm not convinced - a compile error at this point might save a lot of grief later.

David Hibbs 09/14/04 09:30:26 AM EDT

Mr. Tyrrell commented that "...it is the type of the object, not the type of the pointer, that determines the behaviour. To me, that makes it a fault rather than a feature!"

In some regards, yes. The key word here though is "behaviour". Behaviour as in, what happens when a method is invoked? Direct access of fields (IMHO) is not a "behaviour" of an object.

Allowing access to member fields like this is poor style and design in any OO language.

Proper encapsulation helps this problem. This is not to say that encapsulation is a cure-all; indeed, generating getters and setters for the field in the child class (in effect, overriding them and shadowing them at the same time!) can create a whole new set of hard-to-find bugs.

The bottom line: proper design, planning, and review will avoid the pitfall, while the capability to do this is required or else behaviors of parent classes are not encapsulated -- and subject to breakage by children.

J.R. Titko 09/14/04 09:27:52 AM EDT

I have been using this example when teaching for a couple years to show what to avoid in coding Java. It is a situation set up at compile time by the compiler making the substitution of the literal for the variable. I agree its a problem in the language, but can easily be avoided by always using getters and setters to revtrieve instance level variables.

Sebastián Tyrrell 09/14/04 08:10:42 AM EDT

It seems to me from the examples that there is no way of utilising this feature without breaking the Liskov substitution principle that it is the type of the object, not the type of the pointer, that determines the behaviour. To me, that makes it a fault rather than a feature!

Sudipto Nandan 09/14/04 06:41:38 AM EDT

The article is good but can be very briefly eneded by saying that
When a method is called by a reference object, it takes into consideration the Object it is referencing and not the type of referencing object.
While, when a memeber variable is accessed by a reference object, the type of the referencing object is taken into consideration and not the object it is referencing.

MarkusH 09/14/04 05:13:39 AM EDT

This is another example how important it is, that every Developer has easy to use access to Software Audits in it's IDE, so that suspicious constructs like this don't survive until the check-in... i.e. the Audits provided by Borland Together in JBuilder and Eclipse-based IDE's

Narayanan R 09/14/04 12:43:11 AM EDT

It was interesting. It is the behavior of an object that is defined by its type (whose instance it is). I think the attributes of an object are defined by the handle used, since in Java methods are only bound at runtime.
Simple typecasting with the superclass/subclass can have obtained the desired result, as long as the typecast is valid.

Just Nell 09/13/04 09:53:13 PM EDT

Perhaps a better way to demonstrate is to print obj.greeting before setting, e.g.,

A obj = new B();
System.out.println(obj.greeting);
obj.greeting="How are you";

System.out.println(obj.greeting);
System.out.println(obj.toString());