Java methods problem

[Shadow Conception]

I hope I'll be using the right terminology here, so here goes. I have a superclass and its subclass. The superclass is VillainPlayer, and its subclass is Counter. The basic design's like this:

//////////////////////////////////////////////
public class VillainPlayer
{
private int score = 0;

public void act()
{
//the value of score changes
}

public int getScore()
{
return score;
}
}
//////////////////////////////////////////////
public class Counter extends VillainPlayer
{
public void act()
{
System.out.println(super.getScore()); //or even getX() without super, both yield same result
}
}
/////////////////////////////////////////////

Note: Act method is called over and over.

So the problem here is the bolded part. The print statement constantly prints a stream of 0's, no matter what the current value of score is in the VillainPlayer class. The score is constantly changing (adding 100 points every time the mole is hit). Now, getScore works perfectly well inside the VillainPlayer class (inside it's "home" class). However, when a subclass tries to use the getScore method, only 0's are returned instead of the actual int value of score itself.

What could be wrong?

 

[MrChad]

If you call act() on a Counter object, you're not going to change the score value at all, because you've overloaded the base class' implementation.

 

[postmortemIA]

plus, it would be sufficient to call getScore() or this.getScore()

 

[IHateMyJob2004]

Try using the terms parent and child. The child has everything a parent does and more. Kinda like in real life. So Counter is the child in this case. VillainPlayer in this case is also called a "base class". Something that extends nothing. But in Java, everything extends Object even though you don't need to explicitly state this as so. The compiler does this in the background.

Where is setScore(value)?

Also, you might want to consider an interface instead of a base class for something like this. Make an interface called Scorable and make anything that can have a score implement it. This was you can also enforce that a List have only Scorable objects in it.

 

[illvm]

The reason this is happening is because the child class, Counter, is extending the VillainPlayer class and inherits all the properties from the VillainPlayer class but not its data. The score properties of VillainPlayer and Counter share the same name, but not the same location in memory. So when you call getScore() it will call it on the instance of the Counter object and not the VillainPlayer object, so instead of printing out 100,200,etc. for the score that the VillainPlayer has it will print 0 because the Counter object instance's score has not been updated.

It would be nice if you'd also give us some intent for what you're trying to do with the code.

 

[Ken g6]

This is why it's often useful, when extending method X to call super.X() as the first line of the new method. That would fix this specific problem.

 

[presidentender]

Originally posted by: Ken g6
This is why it's often useful, when extending method X to call super.X() as the first line of the new method. That would fix this specific problem.

Almost every constructor I write calls super() first.

 

[Shadow Conception]

Originally posted by: illvm
The reason this is happening is because the child class, Counter, is extending the VillainPlayer class and inherits all the properties from the VillainPlayer class but not its data. The score properties of VillainPlayer and Counter share the same name, but not the same location in memory. So when you call getScore() it will call it on the instance of the Counter object and not the VillainPlayer object, so instead of printing out 100,200,etc. for the score that the VillainPlayer has it will print 0 because the Counter object instance's score has not been updated.

It would be nice if you'd also give us some intent for what you're trying to do with the code.

This was the problem. I went in to ask my teacher about it all, and he pretty much exactly said all this.

I'm using Greenfoot, which contains two different sets of classes: World and Actor. The VillainPlayer and Counter are Actors. The World creates the Actors and sets locations for them on the grid.

The Counter class uses the parent's getX() for its OWN score, which I never declared. The Counter inherited the methods, but not the data of the superclass. I originally thought children inherited the methods AND the data.

The solution was to create a VillainPlayer object (VillainPlayer bob = new VillainPlayer()) in the World class, and send it into the Counter (by changing the Counter's constructor; public Counter(VillainPlayer x)). That way, in the Counter, you could do "myVillain.getX()" and get the exact score I wanted.

I'm really not cut out to be a programmer... well, taking this class helped me decide that! Thanks for the help everybody!

Oh, and what I was trying to do? I made whack-a-mole with keyboard input. It's all based on a 3x3 grid. The main spine behind the whole program is actually really easy.

- randomly generate random locations for VillainPlayer
- write a bunch of if-statements to determine what key corresponds with what location on the grid

if(isKeyDown("q") && getX() == 0 && getY() == 0)
{
//basically means if Q is pressed down, and VillainPlayer is at (0, 0)
//alter score, make explosions, play sounds
}

The Counter was just for bells and whistles. The easy way out would just have been to println the score every time the shot was successful, but that opens up an ugly dialog box for text. So instead, I made a Counter that represented the score on the game screen itself, which (I think) was 10x harder than just println'ing.

This whole game project was actually a lot of fun, though. This is probably the most fun I've had doing work in a class.

 

[SJP0tato]

Originally posted by: Shadow Conception

I'm really not cut out to be a programmer... well, taking this class helped me decide that! Thanks for the help everybody!

...

This whole game project was actually a lot of fun, though. This is probably the most fun I've had doing work in a class.

Maybe you're more cut out to be a programmer than you realized.

Often times during a project programmers aren't super happy about what they're involved with, but once it's complete the satisfaction of a job well done is difficult to match.

 

[illvm]

Originally posted by: Shadow Conception
I'm really not cut out to be a programmer... well, taking this class helped me decide that!

I wouldn't give up all hope. A lot of it comes down into how you're introduced to programming and taught programming techniques.

If you're having issues with Java I would start with a functional programming language first. http://htdp.org/ is a very good book on how to get started thinking about programming is a centered around Scheme. Unfortunately the follow up book to that which is in Java and centers around OO programming rather than functional programming isn't yet finished but some good info from it can be found at http://www.ccs.neu.edu/home/vkp/HtDCH/Materials.html.

If you're interested in programming, stick with it and the thought patterns and skill will come in time.

 

[brianmanahan]

Originally posted by: illvm
The reason this is happening is because the child class, Counter, is extending the VillainPlayer class and inherits all the properties from the VillainPlayer class but not its data. The score properties of VillainPlayer and Counter share the same name, but not the same location in memory. So when you call getScore() it will call it on the instance of the Counter object and not the VillainPlayer object, so instead of printing out 100,200,etc. for the score that the VillainPlayer has it will print 0 because the Counter object instance's score has not been updated.

This is just plain wrong. getScore() called on Counter WILL access the super's getScore() method. The reason that the score didn't get incremented is because Counter overloaded the VillainPlayer act() method, so the logic to change the counter value never got called.