How to avoid reusing identical implementation code with an interface?

Question

First of all, I apologize for "yet another interface question". I thought that this one might be worth asking, though, as it's kind of a strange issue. The project I'm using uses Actionscript 3, but this is more of a general OOP question.

Here's the situation:

I have a class that already inherits from a base class; it's an object in a videogame. (Let's say it's a spaceship.) In my game, I'd like to have many many many spaceships onscreen, at one time, so I've decided to create an object pool using a linked-list structure.

Logically, because class Spaceship already inherits from a base class, I would use an interface to define methods pertaining to a linked list. Doing this, additionally, would allow me to extend these methods to other classes - class Asteroid, or class Bullet, or class Particle, for instance.

Here's the problem - the strength of an interface is that it lets you redefine the implementation for every class you use, based on what you need. For something like a linked list, though, the code isn't going to change between classes. Since I plan on having a lot of classes that will implement these object pool methods, I'd really like to avoid reusing the same implementation code over and over within each new class.

Question: Is there a way to avoid reusing the same exact linked list code for each class I use? Or is this just an inevitability? It seems like this violates the Once and Only Once principle. Is it possible to define a full function within an inheritance block, instead of just its prototype?

If this is a stupid question, let me know. (If I'm asking whether it is, it probably is, but hey, can't learn without being stupid once in a while.) It just seems that there should be a more logical way to do something like this.

Pharyngo

Answer 1

In other languages, that support multiple inheritance, there is an easy way to do it without all your game objects needing to have a common ancestor: your spaceships could inherit from a base ship class, as well as a linked list element class. Unfortunately, AS3 does not support multiple inheritance, so you have to choose to either:

A. Use an interface exactly as you suggest

or

B. Have all your game object base classes inherit from a common ancestor that implements the linked list functionality and extends Sprite (or MovieClip), instead of your game object base classes extending Sprite or MovieClip directly.

I'd probably go with the latter, to solve your exact problem. I'd probably derive from Sprite or MovieClip and call the thing GamePoolObject or something to that effect...

Weird

Also, if you go with the common base class way, you have not lost the flexibility of multiple implementations that the interface would have forced on you, since any of your subclasses can override the functions that implement the linked list behaviors if you need them to. But you probably won't do that often, which is why I think thing base class is better than interface here. – Weird

Yeah. Truthfully, I was wishing for multiple inheritance for this very reason, but so many people seem to hate it. I don't think it's evil - it's just misunderstood. I'm not really a fan of Actionscript's huge inheritance tree - I understand its necessity, but I don't like the fact that I'll have to insert a base class into the tree just to get some methods that I need. Seems to be the Actionscript 3 way, though. – Pharyngo

The other problem is that if I do extend Sprite, or another builtin, what happens when I have classes that don't need to extend any of Flash's core classes? I was pondering that issue a while ago - I believe that you should only inherit when you need the full functionality of the full class. I was thinking about using a base class and an interface for the pool, to have a default implementation, but it seems like that comes with its own set of issues (plus the individual issues of each approach). I guess I"ll have to bite the bullet and use option A. Appreciate your input. – Pharyngo

Extending from Flash's Sprite or MovieClip classes is not a requirement of approach B, I was merely using it as an example, figuring it to be as likely as not that your ships and things were already Sprites. The real restriction with approach B is that all of your game objects that use the linked list functionality would have to inherit from a common base class that implements it. There is no reason your base class couldn't inherit from generic Object, and your game objects like ships, asteroids, etc. own their visual representations by composition (each a different type if you like). – Weird

Answer 2

I never liked using interfaces.
What I would do is make another base class
The first class will be the base class lets call it SpaceObject. All space objects have attributes mass,velocity,friction(if any), rotation. SpaceObject will also extend UIcomponent as we want this to be added to the display list eventually and having inherited methods for hit detection would be nice.
It will also have methods that will handle movement and whatever else needed for space objects.
Then anytime I want to make a new space object I would just extend the SpaceObject class.
public class SpaceShip extends SpaceObject or
public class Commet extends SpaceObject.
These classes will inherit the SpaceObjects attributes plus have their own like how long the tail is or what weapon it has. They should be encapsulated to handle whatever relates to them

Unshakable

Interfaces have their place, for when you need an actual interface that can have multiple implementations: For example, you might make a class that manages communication with a game server and provide it to your game client through an IGameServerConnection interface, and then you might create a dummy server for testing offline which implements the same interface but fakes server responses. I just don't think it's the best solution for this case--I agree with you that it is base class common behavior that is desired, which does not scream "interface" to me, but rather multiple inheritance. – Weird