<< Chapter < Page Chapter >> Page >

The main method of the driver class begins by instantiating a new object of the class A , and saving the object's reference in a reference variable of type Object , named varA .

Call toString method on the reference

Then the code in Listing 4 calls the toString method on the reference variable named varA , saving the returned reference to the String in a reference variable of type String named v1 .

Display the returned String

Finally, that reference is passed to the println method, causing the String returned by the toString method to be displayed on the computer screen.

(In a future module, you will learn that some of the code in Listing 4 is redundant.)

This causes the following text to be displayed on the computer screen:

A@111f71

Pretty ugly, huh?

Nowhere does our program explicitly show the creation of any text that looks anything like this. Where did it come from?

Default toString behavior

What you are seeing here is the String produced by the default version of the toString method, as defined by the class named Object .

Class A does not override toString

Recall that our new class named A does not override the toString method. Therefore, when the toString method is called on a reference to an object of the class A , the default version of the method is executed, producing output similar to that shown above .

What does Sun have to say?

Here is more of what Sun has to say about the default version of the toString method

"The toString method for class Object returns a string consisting of the name of the class of which the object is an instance, the at-sign character `@', and the unsigned hexadecimal representation of the hash code of the object."

You should recognize this as a description of the output produced by calling the toString method on the reference to the object of the class A . That explains the ugliness of the screen output shown above (hexadecimal representations of hashcodes are usually pretty ugly) .

A new object of the class B

Now consider the code shown in Listing 5 , which instantiates a new object of the class named B , and stores the object's reference in a reference variable of type Object .

Listing 5 . A new object of the class named B.
Object varB = new B(); String v2 = varB.toString();System.out.println(v2);

Call toString and display the result

The code in Listing 5 calls the toString method on the reference of type Object , saving the returned reference in the reference variable named v2 . (Recall that the toString method is overridden in the class named B.)

As before, the reference is passed to the println method, which causes the following text to be displayed on the computer screen.

toString in class B

Do you recognize this?

You should recognize this as the text that was encapsulated in the String object by the overridden version of the toString method defined in the class named B .

Overridden version of toString was executed

This verifies that even though the reference to the object of the class B was stored in a reference variable of type Object , the overridden version of the toString method defined in the class named B was executed (instead of the default version defined in the class named Object ) . This is a good example of runtime polymorphic behavior , as described in a previous module.

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Object-oriented programming (oop) with java. OpenStax CNX. Jun 29, 2016 Download for free at https://legacy.cnx.org/content/col11441/1.201
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Object-oriented programming (oop) with java' conversation and receive update notifications?

Ask