Probable overuse of java interfaces in my implementation of Ms. Pac-Man

Question

I have been a Java programmer for the last 6 years, and since the beginning of this year I got interested in game programming. So, I thought it was a good idea to start with a popular game and I implemented the game Ms. Pac-Man in Java. I can say that my implementation looks about 90% similar to the original game, and I tried to used as much design patterns and best practices as possible, since this was just a personal project to learn to code basic 2D games.

Now that I finished the coding, I realized that I have 19 interfaces and just 17 classes! So I start wondering if I might be overusing interfaces.

Here is an example of a few classes/interfaces that I use:

Class - FullGame (implements FullGameInterface and FullGameObservable)

Class - View1 (implements FullGameObserver)

Interface - FullGameInterface (basic functionality methods: resume, pause, play, etc.)

Interface - FullGameObservable (allows views to be registered for update notification)

Interface - FullGameObserver (implemented by the 2 different views of the game to receive notifications)

Am I overusing interfaces?

What is your opinion?

Answer 1

Interfaces are good. It's not a problem to have a lot of them.

Particularly if you've only implemented your first game. If you re-used the code base to build more games, you would probably end up with more polymorphism, because you'd be re-using the interfaces. But at this point, if it's the case that there are more methods in the implementations than in the interfaces, then the interfaces are serving a purpose--they're hiding implementation details from the clients, who are thereby forced to conform to the interface, enabling the polymorphism that is the real benefit of OO.

Answer 2

Use an interface if you want to change the implementation.

For something like your FullGame object, you probably don't need the interface.

If you were to ever change the functionality of FullGame, then you could consider making an interface, so that you can switch which object you instantiate for FullGameInterface.

EDIT 2: Only make the code more complex when you need to. If you think you need an interface, stop first. Use the class that you have already. (But while you use it, try to keep the callers out of the implementation details.) Once you have a second similar class, then you can figure out what's really interface and what's implementation. If your callers still need implementation details that are awkward to put in the common interface, then you're not keeping them cleanly separated enough.

EDIT for a more full answer:

Interfaces are useful for decoupling the methods by which you want to access an object (the interface) from the actual object (the implementation). This is good for several situations:

1. You have more than one implementation of those methods, with the same semantics and general operations, but with different underlying implementations. For example, List, ArrayList, and LinkedList. List is the general interface that allows many collections-based methods to accept either an ArrayList or a LinkedList. The Collection interface permits a similar arrangement for all collections.
2. You need to separate the interface from the implementation for architectural reasons. For example, you could have the calling object on one machine and the implementing object on another. A proxy on the calling machine implements the interface to call across the network to the real object. The interface means that the caller doesn't have to know the difference. Java RMI did this.
3. You need to be able to modify the way that the object is called. For example, take an interface Image and two implementers, FileImage and FileImageProxy. The proxy loads the FileImage on demand and passes calls to the Image interface on to the actual object. The clients never know or care how they get the image, or whether it's really loaded or not; they just know that there's an Image and they can use it.

Answer 3

If you are in control of the code and there is only one implementation, that it is a good sign that the interface is pointless (although it might be useful if you want to, say, test). Remember that inner classes are classes too.

Multiple inheritance of interface, as well as implementation, is usually a bad idea.

Answer 4

I often use interfaces to flesh out my design. I document them thoroughly and this forces me to think through the responsibilities of my classes. There is always some distinction between the API and the internals of a class, so even if you don't have multiple implementations of (yet) it generally does not hurt to specify an interface.