use of "interface"??

[U2_Caparzo]

Hi everyone.
i was reading this post

but i don't understand, as the title says, the use of "interface" in things like Characters, NPCs, etc...
what are the benefits of doing that?

hope someone can help me to understand this.
thanks

[bone-you]

An interface contains only the signatures of methods, delegates or events. The implementation of the methods is done in the class that implements the interface.

aka, you have a class interface that has all the function/method NAMES, that are essentially overridden in another class that then implements them.

[U2_Caparzo]

Originally Posted by bone-you

aka, you have a class interface that has all the function/method NAMES, that are essentially overridden in another class that then implements them.

yeah i have read a bit of interface, but what is the use of them in a CO Pserver source, they are faster than define all the things in each class? or what? oh, and thanks.

[unknownone]

You use an interface to implement polymorphism - the ability to use multiple different types with the same invocations.

To give an example, imagine several separate types which have a method to do the same thing. If we create an instance of each one, we invoke the method on them separately. This is valid code with no particular issues.

class Monster {
    void Move(Direction d) { ... }
}
class Player {
    void Move(Direction d) { ... }
}

Player p = new Player();
Monster m = new Monster();

p.Move(Direction.North);
m.Move(Direction.North);

A problem might come if I write another function which requires the use of the Move function, such as a path-finding function. I don't know whether or not to pass a Monster or a Player to the function. (Do I pass both, or do I pass an "object"? Or do I write a separate pathfinding function for each one, replacing Player with Monster?). None of these are particularly good ways of doing this. An example of how it might look passing 'object' around.

void MoveTo(Location destination, object playerOrMonster) {
    if (playerOrMonster is Player) { 
        var player = (Player)playerOrMonster;
        ... //pathfinding stuff.
        player.Move(...);
    }
    else if (playerOrMonster is Monster) { ... }
}

It's necessary to perform the type check and case, because you can't call .Move() on the 'object' type - and if you attempt to cast an object to the invalid type, you will get an exception.

And of course, if you have multiple other functions which invoke Move(), you need to add that kind of selection to each one individually.

The correct way to solve the problem is to take all the types which are required under a common interface, so that you can use the same invocation, regardless of the type you are using.

interface IMoveable {
    void Move(Direction d);
}
class Monster : IMoveable {
    public void Move(Direction d) { ... }
}
class Player : IMoveable { 
    public void Move(Direction d) { ... }
}

void MoveTo(Location destination, IMoveable playerOrMonster) {
    ... //Not necessary to determine which type playerOrMonster is.
    playerOrMonster.Move(...);
}

Whether the code here calls Monster.Move or Player.Move is determined at runtime based on it's type - so you don't need to check it. The compiler converts interface calls to virtual calls, which are looked up in a "vtable" during runtime. This has a slight overhead compared with a regular, non-virtual method call, but the overhead is tiny, so it's not worth worrying about. Compared with the first MoveTo example though, where we would be manually checking the type - the virtual call is faster due to optimisations.

That's the basic idea of interfaces anyway. You can acheive similar results using classes with abstract or virtual methods too, which can also hold data and offer more flexibility. The choice between interface and abstract class is not always clear, and requires a bit of experience before you can make suitable decisions.

[U2_Caparzo]

Originally Posted by unknownone

You use an interface to implement polymorphism - the ability to use multiple different types with the same invocations.

To give an example, imagine several separate types which have a method to do the same thing. If we create an instance of each one, we invoke the method on them separately. This is valid code with no particular issues.

class Monster {
    void Move(Direction d) { ... }
}
class Player {
    void Move(Direction d) { ... }
}

Player p = new Player();
Monster m = new Monster();

p.Move(Direction.North);
m.Move(Direction.North);

A problem might come if I write another function which requires the use of the Move function, such as a path-finding function. I don't know whether or not to pass a Monster or a Player to the function. (Do I pass both, or do I pass an "object"? Or do I write a separate pathfinding function for each one, replacing Player with Monster?). None of these are particularly good ways of doing this. An example of how it might look passing 'object' around.

void MoveTo(Location destination, object playerOrMonster) {
    if (playerOrMonster is Player) { 
        var player = (Player)playerOrMonster;
        ... //pathfinding stuff.
        player.Move(...);
    }
    else if (playerOrMonster is Monster) { ... }
}

It's necessary to perform the type check and case, because you can't call .Move() on the 'object' type - and if you attempt to cast an object to the invalid type, you will get an exception.

And of course, if you have multiple other functions which invoke Move(), you need to add that kind of selection to each one individually.

The correct way to solve the problem is to take all the types which are required under a common interface, so that you can use the same invocation, regardless of the type you are using.

interface IMoveable {
    void Move(Direction d);
}
class Monster : IMoveable {
    public void Move(Direction d) { ... }
}
class Player : IMoveable { 
    public void Move(Direction d) { ... }
}

void MoveTo(Location destination, IMoveable playerOrMonster) {
    ... //Not necessary to determine which type playerOrMonster is.
    playerOrMonster.Move(...);
}

Whether the code here calls Monster.Move or Player.Move is determined at runtime based on it's type - so you don't need to check it. The compiler converts interface calls to virtual calls, which are looked up in a "vtable" during runtime. This has a slight overhead compared with a regular, non-virtual method call, but the overhead is tiny, so it's not worth worrying about. Compared with the first MoveTo example though, where we would be manually checking the type - the virtual call is faster due to optimisations.

That's the basic idea of interfaces anyway. You can acheive similar results using classes with abstract or virtual methods too, which can also hold data and offer more flexibility. The choice between interface and abstract class is not always clear, and requires a bit of experience before you can make suitable decisions.

thanks for ur awesome answer

[InfamousNoone]

One big thing to consider though when taking into consideration abstract classes vs interfaces is that in .NET, you may only inherit from one class (obviously, besides Object) where as you can implement an unlimited amount of interfaces.

The first time I started developing a server I thought they were pretty useless, but I quickly learned how powerful they can be!

[bone-you]

boo. In C++, interface is just an adopted word. abstract does exist though, and is only defined when a function = 0.

class SomeClass
{
virtual void Move() = 0;
}
^ abstract, but the only difference between something like that and a plain virtual function ( virtual void Move(); ) is that an abstract class must have EVERY abstract function implemented whereas a virtual function does not have to be overridden or implemented.



If anyone is interested in learning moar on the c++ side. Not sure if it's exactly the same as it is in C#, don't know if you can even do a function = 0 lol. Would be nice if Microsoft didn't try to invent languages and create their own nonstandard conventions.

[InfamousNoone]

Originally Posted by bone-you

boo. In C++, interface is just an adopted word. abstract does exist though, and is only defined when a function = 0.

class SomeClass
{
virtual void Move() = 0;
}
^ abstract, but the only difference between something like that and a plain virtual function ( virtual void Move(); ) is that an abstract class must have EVERY abstract function implemented whereas a virtual function does not have to be overridden or implemented.



If anyone is interested in learning moar on the c++ side. Not sure if it's exactly the same as it is in C#, don't know if you can even do a function = 0 lol. Would be nice if Microsoft didn't try to invent languages and create their own nonstandard conventions.

Interfaces in C# are modeled the same way they are in Java. Sun set the standard for what a "true" interface would be in a higher-level language.

If a class inherits from an abstract class, you're forced to implement all it's abstract methods. Essentially an abstract function is a virtual function with the value null as you demonstrated above. Where as, a virtual function has been at least defined by the base-class, but may be optionally over-ridden by the child class.

[I don't have a username]

Interfaces are also a great thing to use, when you're creating classes which has to contains a lot methods and properties, because it makes sure you won't forget anything as it requires you to implement all of them.

Regarding abstract classes. If you only want a few methods/properties/etc. to be different, when implementing it on more than one class, then it's a good thing to use, however as mentioned you can only implement one abstract class, but as many interfaces as you want. You can have both an abstract classes and interfaces tho.

It took me a while to understaand why interfaces were useful :P

[unknownone]

Originally Posted by bone-you

boo. In C++, interface is just an adopted word. abstract does exist though, and is only defined when a function = 0.

class SomeClass
{
virtual void Move() = 0;
}
^ abstract, but the only difference between something like that and a plain virtual function ( virtual void Move(); ) is that an abstract class must have EVERY abstract function implemented whereas a virtual function does not have to be overridden or implemented.



If anyone is interested in learning moar on the c++ side. Not sure if it's exactly the same as it is in C#, don't know if you can even do a function = 0 lol. Would be nice if Microsoft didn't try to invent languages and create their own nonstandard conventions.

While C++ offers a bit more power, multiple inheritance can shoot you in the foot. It's also an extreme pain to implement at the compiler level, which is one of the big reasons it was avoided in Java/C# etc.

Java went with using an annotation for abstract, where C# added a keyword for it. There was discussion during the C++0x standardization process as to whether to include an [[abstract]] attribute too, but it was deemed unnecessary, since it wouldn't be adding anything new.

The C++ inheritance model is borrowing from the Java/C# model in other ways too. Explicit overrides, final/sealed methods, and new methods have been thrown into C++11 using attributes, but you still need to mark your inheritance model with "explicit" to use them properly.

I personally like the single inheritance with mixins model, which offers most of the flexibility of multiple inheritance, with less of the side effects. Languages like D, Scala use this model.

[IAmHawtness]

Originally Posted by unknownone

Languages like D, Scala use this model.

D is an amazing language, it's too bad that it's not very popular

[I don't have a username]

Originally Posted by IAmHawtness

D is an amazing language, it's too bad that it's not very popular

Actually...

Originally Posted by cinik

To be honest, I never liked idea of D, it's still not good enough to be substitution for C/C++ and it will never be. MS is standing behind .net/C++, open source community still support C/C++/Java/Python/Haskell/... name it, and there is not enough space for D to fit in and become mainstream. Each of these programming languages has it's own use and it's still mainly used in IT, D is supposed to come as ultimate solution/answer to all the features these programming languages lack. Digital Mars has not enough power to propagate D among users, even shitty VBS got more programmers than D and MS didn't quit its support, VBS is still being supported on every windows, including win8. So, nope, stick to C/C++/C# or anything I named above, you won't make mistake. D is just dead end.[hr]
Why Intel Itanium died? It was fairly a good solution, nice processor archicteture, why don't people move to x64, there is still a shitload of people using old windows xp. You can't create standard by just offering "better solution, claiming that your X has better features than Y" and hope people will buy into that. People just want what is easy to use, popular, can get the shit done, and that's all. So, yeah, once again, choose C/C++.[hr]
Considering there are so many applications coded in C/C++ it would be kinda dumb to move "something else". All that code needs to be maintained, patched, recoded, I don't think that C++/C will "die" in next 20 years. Its standard will surely be redefined, you have C11 now, but there are still no compilers that support any of those features. MSVC support only C89 . And I personally don't see anything really "amazing" that would D offer instead C++.

[IAmHawtness]

Originally Posted by I don't have a username

Actually...

Actually what? Nothing in that quote has anything to do with D not being a good language. Like I said, it's a shame it's not more popular.