wood burning stoves*
The moose likes Beginning Java and the fly likes Changing a variable reference from a Superclass object to Subclass Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Changing a variable reference from a Superclass object to Subclass" Watch "Changing a variable reference from a Superclass object to Subclass" New topic
Author

Changing a variable reference from a Superclass object to Subclass

Bren Reggy
Greenhorn

Joined: Feb 02, 2012
Posts: 12
I am trying to create a rock paper scissors game and the trouble I am having is referencing the change of object.



It seems that when I cast the object playerObj from superclass "Tool" to any of the subtypes, the scope outside the switch statement doesn't register the change and continues to maintain that it is of type "Tool" rather than the new object cast. I need playerObj to be of whatever type playerChoice was, (i.e. if choice was 3, then its Scissors playerObj rather than Tool playerObj)

Any suggestions of a fix?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14270
    
  21

You probably misunderstand what casting does.

Casting does not convert objects or variables to a different type. The only thing that a cast does, is tell the compiler "I have an object here and I want you to treat it as if it is of type X; don't complain if you can't verify that it is really an X".

The casts in your code above do absolutely nothing at all. They don't convert an object to the type that you cast to. They also don't change the type of the variable playerObj (in fact, it is not possible at all to change the type of a variable at runtime).

Why do you think you need to do these casts?

You should make use of polymorphism. Throw away the whole switch (lines 5 to 16) and override the toString() method in your classes Rock, Paper, Scissors, Lizard and Spock. When you do that, then you'll see that the call in line 18 automatically calls the toString() method in the appropriate class.

By the way, the code as it is will throw a NullPointerException in line 18, because playerObj is null and in line 18 you're trying to call a method on it. Calling a method on a variable that's null will cause a NullPointerException.

Maybe you meant to write something like this:


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Jesper de Jong wrote:
Casting does not convert objects or variables to a different type. The only thing that a cast does, is tell the compiler "I have an object here and I want you to treat it as if it is of type X; don't complain if you can't verify that it is really an X".


Not meaning to muddy the waters, but I think it's worth pointing out that casting primitives does actually do value conversion. However, when dealing with references, as Jesper states, it doesn't affect the object at all--just tells the compiler, "I know you think this is a Y, but trust me, it's an X, so treat it as such."
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39415
    
  28
Whose bright idea was it to use the same word “casting” for primitive casting and reference type casting when the two processes are so different?
Bren Reggy
Greenhorn

Joined: Feb 02, 2012
Posts: 12
Sorry, I meant to write that the problem was a NullPointerException as the Tool playerObj was instantiated as null and didn't recognise the casting (which I understand now was wrong anyway).



The problem still with the playerObj is that it references the boolean default values (false) of the Tool superclass even after;



What I am aiming for is that when the Player makes his choice (via Console) through an int selection (i.e. 1 for Rock, 2 for Paper, etc.), the playerObj variable is assigned that object and uses the objects classes' boolean values., rather than Tool's. I thought I had been overriding the boolean values.

I used a switch statement to assign the objects to the int choice and the toString() to confirm in runtime it was working.

Appreciate (and appreciated) all help.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19720
    
  20

Bren Reggy wrote:Sorry, I meant to write that the problem was a NullPointerException as the Tool playerObj was instantiated as null and didn't recognise the casting

That had nothing to do with casting. What happens if the player choice is 0, or 6, or 483?


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Bren Reggy wrote:Sorry, I meant to write that the problem was a NullPointerException as the Tool playerObj was instantiated as null and didn't recognise the casting


Just to clear up a couple of things...

No object is ever null in Java. Only references can be null. Nothing is ever "instantiated as null." What you're describing is that the playerObj variable was initialized to null. (Instantiation applies only to classes, not references or variables.)

The null had nothing to do with the cast problem. Null can be cast to any reference type, and casting doesn't give NullPointerException (except perhaps when auto-unboxing is invlolved).
Bren Reggy
Greenhorn

Joined: Feb 02, 2012
Posts: 12
Rob Spoor wrote:
Bren Reggy wrote:Sorry, I meant to write that the problem was a NullPointerException as the Tool playerObj was instantiated as null and didn't recognise the casting

That had nothing to do with casting. What happens if the player choice is 0, or 6, or 483?


If a player picks a choice beyond the 5 or a letter, it will throw an error. I will streamline and bug-prevent once I get the program into at least a runnable state.

Jeff Verdegan wrote:Just to clear up a couple of things...

No object is ever null in Java. Only references can be null. Nothing is ever "instantiated as null." What you're describing is that the playerObj variable was initialized to null. (Instantiation applies only to classes, not references or variables.)

The null had nothing to do with the cast problem. Null can be cast to any reference type, and casting doesn't give NullPointerException (except perhaps when auto-unboxing is invlolved).


I realise I am getting my terminology mixed up and more than likely I have not been explaining myself correctly.

Regardless, thank you for your help, especially Jasper!
I believe I have now fixed the problem!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Changing a variable reference from a Superclass object to Subclass