Alternative to extending classes from interfaces?

[TacoManStan]

Hey guys! Well I am relatively new to Java, and although I am learning fairly quickly, I am sort of stuck as to what to do about the layout of my classes.

I am making a game (surprise surprise, as I am in High School, what else what I do with programming? ) that is designed similarly to the funcionality of Pokemon. The camera is set an an angle at the player, which is always in the middle of the screen. When the player moves, everything around him moves, he actually stays in one place while everything around him moves. (Like an RPG camera)

Here is where I begin to get stumped. There are a couple of different types of objects that can be drawn to the screen. The player unit, which contains data specific to the human player. There are units, which are items that can be interacted with, but also can move. There are terrain objects, which will not move. They can be interacted with, but not always, depending on the object and the circumstance.

I was going to use an interface to store methods that all these items use, and then set up a couple classes to control each item. I was using a lot of if-then statements, but that seemed incredibly inefficient. Using an interface I can use methods without necessarily knowing what the object is, which is great. However, as I was making the classes, I noticed that I was still repeating a lot of code, with only some minor changes. Some methods are actually identical, such as the "getGameX()" and "getGameY()" methods. No matter what type of object it is, it always has the same type of position.

So I guess my question is, is there a better way to do this? Is there NO way to define methods that are to be the same for all of the classes implementing the interface? Should I even be using an interface?

[sunde887]

My suggestion is to use an abstract skeletal class. Which still uses the interface, this is actually used in the collections class(check the source for AbstractXxx, where Xxx is the type of collections).

The basic implementation will look like this

public interface Common{
  //methods that all will have
}

public abstract class AbstractCommon implements Common{
  //default implementations of methods
  //for methods which are unique for all
  //classes and a default is not necessary
  //declare them abstract
}

public class ClassOne extends AbstractCommon{
  //override functionality of methods if necessary
  //otherwise inherit them
}

public class ClassTwo extends AbstractCommon{
  //same as ClassOne
}

[TacoManStan]

Thanks! Had totally forgotten about abstract classes. The only issue is that all my classes that implement the interface already extend JComponent. Is there some way around that?

EDIT: Also, why would having an interface and an abstract class be necessary? Besides potential future programs or classes (which I found doubtful, as this is more of a learning project than anything) is there a purpose?

[sunde887]

Original question: You can have the abstract class extend JComponent and implement the interface.

public abstract class AbstractCommon extends JComponent implements Common{
 ...
}

Although make sure you think before extending JComponent. If the object isn't a JComponent it shouldn't extend it. If possible, it's better to prefer composition.

To the edit:
This is taken directly from Effective Java by Joshua Bloch, p.94:
"...Interfaces enable safe, powerful functionality enhancements..."
"...While interfaces are not permitted to contain method implementations, using interfaces to define types does not prevent you from providing implementation assistance to programmers. You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface you export..."

I'm aware this is a personal assignment so all of this doesn't apply, but getting into the habit of thinking of these things will be valuable. Even if it's just for learning, or just for you, you should still consider the best way to implement.

Here is a more precise excerpt:
"...Existing classes can easily be retrofitted to implement a new interface. All you have to do is add the required methods if they don't yet exist and add an implements clause to the class declaration..."

Basically, it creates more flexible code, and as this section in the book(which starts on page 93) is titled: "Prefer interfaces to abstract classes".

Basically, you want to try and use interfaces and you are providing an abstract skeletal class as stated above. There are certainly more reasons to design the type hierarchy to be robust and flexible.

[TacoManStan]

Thanks a ton! Really been a ton of help.

So basically what you are saying is that I am using a skeletal class to define methods of the interface that all of MY classes are going to extend? Then, if someone else wanted to use the interface, they could without requiring use of the skeletal class at all, if they don't need it?

Also the items are JComponents. They are being printed directly onto a JLayerdPane. Unless there is another way of doing that, I don't think I have a choice but to extend JComponent somewhere. (Unless there is something like Threading, where you can just implement Runnable or something. Extending just seems easier in this case, even if such an interface does exist)

[Fubarable]

There's almost always a way of getting around extending/inheritance. A common way for instance is to use composition in lieu of inheritance. For instance, please have a look at this article: Inheritance versus composition: Which one should you choose?, plus many others that you can find via Google.

Edit: on re-reading the replies in this thread, I see that my comment is not quite original and that sunde887 already espoused composition in his second reply in this thread (post #4).