I would say you should not use an interface. A better approach would be to use a superclass. With a superclass you can avoid redefining many of the methods that will, presumably, be shared by both the rival and the hero. Here is an example implementation:
Superclass:
public abstract class ExampleFighter {
private String name;
private int health;
private boolean isDead = false;
public ExampleFighter(String name, int health) {
this.name = name;
this.health = health;
}
public void attack(ExampleFighter ef) {
int damage = 0;
//calculate damage dealt
damage = 10;
ef.takeDamage(damage);
}
public void takeDamage(int damage) {
//manipulate the amount of damage taken
if(health - damage <= 0) {
health = 0;
isDead = true;
} else {
health -= damage;
}
}
public boolean isDead() {
return isDead;
}
}
Subclasses:
public class ExampleHero extends ExampleFighter {
int reputation; //the general opinion of the hero
public ExampleHero() {
super("Hero Oreh of Herosville", 100);
reputation = 0;
}
public void improveReputation() {
reputation++;
}
}
public class ExampleRival extends ExampleFighter {
public ExampleRival() {
super("Your greatest rival", 101);
}
}
The side effect of this system is that it requires a fourth class to actually play the game:
public class ExampleGame {
private ExampleHero hero;
private ExampleRival rival;
public static void main(String... args) {
ExampleGame game = new ExampleGame();
game.start();
}
public ExampleGame() {
hero = new ExampleHero();
rival = new ExampleRival();
//what ever other game setup you need to do.
//alternately you could have a load() method
//that takes care of most of this.
}
private void start() {
//make your run loop or query the user for input
//or whatever you need to do. I will create an
//example run loop
boolean running = true;
while(running) {
//this whole block should be moved
//to another method called gameUpdate()
//or something similar but since this
//is a quick example I'll just leave it
//here
hero.attack(rival);
rival.attack(hero);
if(rival.isDead()) {
hero.improveReputation();
System.out.println(“Your rival is dead!");
running = false;
} else if(hero.isDead()) {
System.out.println("you died :(");
running = false;
}
}
}
}
Now this might seem a bit complicated but it illustrates a very important concept: separation of concerns. Separation of concerns involves putting code and making classes that make sense. A player should not know who it’s rival is, player might not even know that enemies exist or what sort of terrain it’s standing on. But a player should know how to manage it's health, it's name, how to take damage, etc. In contrast a Game object would need to know about all the players and enemies so it can tell them to fight and move around on the screen. This is an informal definition of seperation of concerns, for more accurate information read the wikipedia page. In this example I separated the hero and the rival so that, later, you can add more enemies without having to modify your hero code every time. This system also allows you to expand on the game's UI without affecting the player or rival. If you wanted to add a GUI to your game you could add an initialize() method in ExampleGame that setup the GUI. Then in the game loop you could call methods to draw images and graphics onto the GUI. With seperation of concerns you can make the system far more modular and easy to use.
Your second question is: why do we use interfaces? Interfaces are a way of making sure that other classes have a behavior you need them to have, without specifying exactly how they should do it. A classic example of the use of interfaces is the Comparable interface. The Comparable interface has one method that it’s must be implemented: compareTo(). The purpose of this method is to allow a ranking of value objects (think String or File) that cannot use the standard boolean mathematical operations (<, >, ==, etc.) You can think of it as like signing a contract. You (the class implementing the interface) agree to have a certain set of functionality however you make that functionality is up to you. For more information read the java tutorial
I should add a caveat to this answer: Inheritance is not the best option. If you want to know how to do it right you should look up MVC (Model View Controller) and Component Based Design. Even these may not the best choice for what you're doing but they're good starting points.
