No. You are missing the point with interfaces. They don't come from the class that you inherit from. They are a definition of an additional set of methods and fields that you can implement in any class irrespective of what it is derived from.
As I said, this allows you to overcome the fact that multiple inheritance is not available. It is a clean and natural way of doing what multiple inheritance would be useful for without the ugly issues.
In shorthand:
Interface I
Type A
Type B Extends A Implements I
Type C Extends A (but does not implement I)
Type P
Type Q Extends P Implements I
Type R Extends Q (and therefore also implements I)
So types B, Q and R all implement interface I and could therefore be passed to a method expecting something that implements I.
And don't tell me that P should de derived from A because that may not be possible or desirable. Accept that P and A may be completely unrelated but that you want them to be able to perform some set of things in common.
Examples of what an interface could be providing:
- Methods to save and load a type in a standard way where the types may be as unrelated as game settings, player and enemy units, window positions, high score table. Call this IPersist for example.
- Methods to update objects (say with gravity in the case of masses) and draw them to the screen where the objects may vary from ships to waypoints to information dialogs. Call this IUpdate.
- AI methods to say navigate to a position (INavigate) or control weapons (IWeaponControl) for anything from ships and missiles to ground bases.
And these could be different interfaces that objects implement zero or more of. Of course if a class implements an interface then so do the descendents of the class.
Try to build all this using a single inheritance hierarchy and you end up with an unwieldy and fragile hierarchy with nonsensical possibilities (like a window that can navigate itself or could be asked to fire upon a target). Build it as separate hierarchies but with common sounding methods but the same named methods are not in fact type compatible. You could not pass unrelated types as a parameter since they are incompatible.
Where it really comes into play is if somebody produces a library and publishes the interfaces. There will be lots of routines that they provide that accept parameters that implement various interfaces. Then YOU can implement the same interfaces in YOUR types and bingo the library can be applied to them as well. No need to derive your types from their base types.
The concept of interfaces is massively useful but if you haven't come across it before you'll think it is all solvable with Extends and Abstract.
At a guess, the reference to TMax2DGraphicsDriver(g) that you saw would be a cast or a test to see if g is of that type. The BM syntax for this is confusingly different to other languages that I use.
We agree on the lack of overloading being bad.
I know that the new method is called up the chain. My gripe is that since new does not allow parameters you can't set parameters like in my third code example but have to laboriously write CreateXYZ methods all the way up the chain. Have another look at the wishlist code. I think it is the most concise way of doing this. It is based on how C# works.
As I said, this allows you to overcome the fact that multiple inheritance is not available. It is a clean and natural way of doing what multiple inheritance would be useful for without the ugly issues.
In shorthand:
Interface I
Type A
Type B Extends A Implements I
Type C Extends A (but does not implement I)
Type P
Type Q Extends P Implements I
Type R Extends Q (and therefore also implements I)
So types B, Q and R all implement interface I and could therefore be passed to a method expecting something that implements I.
And don't tell me that P should de derived from A because that may not be possible or desirable. Accept that P and A may be completely unrelated but that you want them to be able to perform some set of things in common.
Examples of what an interface could be providing:
- Methods to save and load a type in a standard way where the types may be as unrelated as game settings, player and enemy units, window positions, high score table. Call this IPersist for example.
- Methods to update objects (say with gravity in the case of masses) and draw them to the screen where the objects may vary from ships to waypoints to information dialogs. Call this IUpdate.
- AI methods to say navigate to a position (INavigate) or control weapons (IWeaponControl) for anything from ships and missiles to ground bases.
And these could be different interfaces that objects implement zero or more of. Of course if a class implements an interface then so do the descendents of the class.
Try to build all this using a single inheritance hierarchy and you end up with an unwieldy and fragile hierarchy with nonsensical possibilities (like a window that can navigate itself or could be asked to fire upon a target). Build it as separate hierarchies but with common sounding methods but the same named methods are not in fact type compatible. You could not pass unrelated types as a parameter since they are incompatible.
Where it really comes into play is if somebody produces a library and publishes the interfaces. There will be lots of routines that they provide that accept parameters that implement various interfaces. Then YOU can implement the same interfaces in YOUR types and bingo the library can be applied to them as well. No need to derive your types from their base types.
The concept of interfaces is massively useful but if you haven't come across it before you'll think it is all solvable with Extends and Abstract.
At a guess, the reference to TMax2DGraphicsDriver(g) that you saw would be a cast or a test to see if g is of that type. The BM syntax for this is confusingly different to other languages that I use.
We agree on the lack of overloading being bad.
I know that the new method is called up the chain. My gripe is that since new does not allow parameters you can't set parameters like in my third code example but have to laboriously write CreateXYZ methods all the way up the chain. Have another look at the wishlist code. I think it is the most concise way of doing this. It is based on how C# works.