Digital Edition

SYS-CON.TV
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.

About Yakov Fain
Yakov Fain is a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay. He wrote a thousand blogs (http://yakovfain.com) and several books about software development. Yakov authored and co-authored such books as "Angular 2 Development with TypeScript", "Java 24-Hour Trainer", and "Enterprise Web Development". His Twitter tag is @yfain

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

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.

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.

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".

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.

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.

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.

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!

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.

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

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.

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());




ADS BY GOOGLE
Subscribe to the World's Most Powerful Newsletters

ADS BY GOOGLE

CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018,...
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news an...
DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing w...
Disruption, Innovation, Artificial Intelligence and Machine Learning, Leadership and Management hear...
Enterprises are striving to become digital businesses for differentiated innovation and customer-cen...
DXWorldEXPO LLC announced today that Telecom Reseller has been named "Media Sponsor" of CloudEXPO | ...
"Calligo is a cloud service provider with data privacy at the heart of what we do. We are a typical ...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As au...
"We host and fully manage cloud data services, whether we store, the data, move the data, or run ana...
Enterprise architects are increasingly adopting multi-cloud strategies as they seek to utilize exist...
In this Women in Technology Power Panel at 15th Cloud Expo, moderated by Anne Plese, Senior Consulta...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitori...
Adding public cloud resources to an existing application can be a daunting process. The tools that y...
DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, ...
Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud,...
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use ...
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost...
DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 20...
In this presentation, you will learn first hand what works and what doesn't while architecting and d...
Everyone wants the rainbow - reduced IT costs, scalability, continuity, flexibility, manageability, ...