Classes vs Interfaces

I don't know if this has been dealt with before, but why are so many obvious interfaces implemented as classes? Is this for performance reasons? I'm thinking of the things to do with input handlers that have been changed to classes, and stuff like PhysicsUpdateCallback in jmePhysics2 which replaces an interface in jmePhysics.

If there's no performance reason for this (and a quick look through google results and asking a few people suggests there should be no performance difference at all) then I would say that an interface is a far better choice for most of these things, and if an interface has been good enough up to now, I don't see why it should become a class. Ideally it would be great to have interfaces everywhere possible, but I realise this can be a chore to implement. However for things that will be frequently implemented by users, I really think that interfaces should be available.

What classes in the input system do you mean? i.e. InputAction contains attributes and accessors…

In general interfaces are fine. Some are classes for convenience. Others are classes because they have crucial base implementation which should not or cannot be done in subclasses. Though interfaces can be slower than abstract classes in some cases, I don't think some interface was made a class because of these.

re PhysicsUpdateCallback: I changed that recently in my local copy. It was a class (and it was in the old one, too) because it had four methods where usually only one was implemented. In the JDK the *Adapter classes fulfill the same purpose.

I'll keep a note of any classes I run into that might be useful as interfaces, for now the only examples I have in front of me are InputAction and PhysicsUpdateCallback.

Looking at InputAction, I can see that it has properties, but personally I would still want to have an InputAction interface then an AbstractInputAction that implemented those properties, to leave open the option of reimplementing. The amount of code in the existing InputAction wouldn't be very hard to reimplement. It seems like it would be easier to start from interfaces, and leave the option open, than to have to work round this in future.

The PhysicsUpdateCallback would be another good example, since the Adapter classes in Swing for example are normally implementations of an interface, so you can use them if you want, or use the interface. Again this gives an interface and a class, which might be a little more work now, but leaves things open for the future. Swing is actually a really good example of how lack of interfaces can cause problems as well, because in many places there are abstract classes that I daily wish were interfaces :wink: The main case is when it would be great to make an existing class implement an interface, and this would be the most natural way to do things, but it is made impossible since the existing class cannot subclass more than one class. The interface, then abstract implementation, then concrete implementation way of doing things always leaves everything open at all points. It might be overkill to do this for every class, but for things like callbacks it seems very worthwhile.

Just to do a bit more pointless complaining… I keep getting confused writing input and physics code, since I expect listeners to be called xxxListener, and to add these with addSomethingListener, but most methods using this pattern have different names like callback, action and handler :slight_smile: I always forget which term applies to the thing I'm using.

Well, I think in most cases it's really good to have a separate class that implements that interface. So if abstract classes force people to do so - it forces them to make a better design (IMO of course :P)

If you really need an interface somewhere instead of a class, feel free to suggest that. But I still think in many cases it's really better to have a class if there is certain behaviour that is expected from implementors and can be implemented by an abstract class already.

Hmm, Listener vs. Action vs. Callback etc. . . . What about naming all of them Observers according to the gang of four XD . . . really you should get used to it :slight_smile:

And I think there are subtile differences between them, too. 'Listener' e.g. suggests that the one who is reacting on i.e. an event is not that important to the operation of the firing object. 'Action' on the other hand suggests that it is somewhat mandatory. 'Handler' also seems to be quite important but usually there can be more of them, e.g. to form a chain of responsibility or similar strategies… so I think all of them have their right to exist. Finally 'Callback' hints that it is invoked at a time known to the regsitrant but e.g. at a time it usually cannot execute code (e.g. within physics processing). To summarize all of could be seen as observers but not listeners.

Ok, enough nitpicking for today, I assume.

Definitely this is primarily a discussion of preference, but typically what seems the best way to me is to have an interface and a default implementation (and prehaps an adapter that the default implementation extends) for aspects that will commonly need to be implemented explicitly, such as a listener, callback, etc.  In a situation where the implementing developer wishes to implement the entire functionality themselves if you want to get technical it is more efficient to have an implementation of an interface than it is to have an extension of an abstract class.  For obvious reasons there is no hierarchy imposed upon an interface other than structure whereas in an abstract class there is two classes that must be referenced for content and a hierarchical decision making process enforced.  I don't think it makes much of a difference in noticeable speed, but the only thing I would care about is the benefits structurally of utilizing interfaces where they make sense.  However, I've noticed there are typically two extremes here: Those that use interfaces for EVERYTHING, and those that never use interfaces at all.  Not saying either of you fit into one of those categories, just making a random statement. :wink:

However, I'm not writing this API and my assumption is that shingoki has no code in it either.  We can all be grateful to Irrisor for taking his spare time to develop this and allowing us the benefit of it.  Shingoki, I would submit if you find anything that you think is extremely bad, post an alternative in code and then we can weigh the advantages then without imposing an idea that Irrisor would then have to be responsible for dealing with himself.

********* Daily rant ends here **********


why don't we convert all jme classes to interfaces so that anyone could implement jme from scratch?!  8)

MrCoder has correctly demonstrated one of the extremes I mentioned…do we have a volunteer that can tell us which one? :-p


I agree with Darkfrog about reasons for interfaces, and also I agree that whoever is writing the code is the one who should decide how to implement it, I'm also grateful for all the good free code, thanks irrisor and all devs :slight_smile:

I agree with irrisor that sometimes abstract classes are useful to enforce behaviour, but it's normally a good idea to also document that behaviour so that if it can be enforced a different way, other implementations then know what to do if they implement an interface. Having code that tries to enforce a contract is never bulletproof because it is normally possible to override a superclass method and break it completely.

On the submitting code front - I've been working on some code that I think is useful for dealing with physics, for example where you want a loosely coupled physics object which will move around according to "fake physics" (setting position directly, etc.) when not in contact with anything else, but then use physics to resolve collisions when touching other objects. The code is available at although at the moment it uses jmephysics1, not 2, since I can't get terrain working in jmephysics2 :slight_smile: If any of this code is useful, I would be very glad to help make it more general, etc. I think the only effect the interfaces/classes thing would have is that not using interfaces might make it slightly more difficult for people who tend towards the interfaces approach to integrate code like this into existing code, but I can't say it would actually put me off doing it :slight_smile:

Code to change both the things I asked about would be very simple using a refactoring tool, just extract an interface from the class, and it's done. It would probably break existing code using the classes though, so it might be too late :frowning: Perhaps just changing the PhysicsUpdateCallback would be good, with an Adapter as an empty class as discussed.