XNA-Mordt

Could anyone point me in the right direction regarding programming c# with interfaces. I've googled up the subject and whilst there are some good tutorials on how to do it, non of them really explain in simple terms why we should or shouldn't. I just can't seem to get my head around how they work properly.


Re: XNA Game Studio Express Interfaces

parlance

Interfaces in any language represent a blueprint for how a class is to be built, a specification, if you will, and don't actually contain any code themselves. When a class inherits from an interface, it basically says that it meets a certain set of criteria that is defined in that interface. This criteria in C#'s case means that every method and member that is defined in the interface is also defined in the class that inherited from it. This allows code that interface with classes that may behave differently, but provide a similar interface. One example is a List interface, that might have methods like AddItem, RemoveItem. You might create a linked list class that inherits from that interface and an array list class that inherits from the same interface. The advantage here is that you could easily write code that could use either class for storage because the "interface" between them and your code is the same.

XNA implements game services in this manner to promote code re-usability. Consider an interface that might define some of the methods that a physics engine could provide, like checking for collision detection, and integrating object's positions over time. If you had a game that used a physics engine in this manner, you could easily replace that physics engine without having to modify any of the game code by writing your own physics engine class that would inherit from the same interface.

Hope this helps.





Re: XNA Game Studio Express Interfaces

Robin Debreuil

You often use interfaces when a group of classes have a similar behaviour but are otherwise unrelated. Sometimes this is because they can all do a second 'trick', like generate log data, but you don't want them to all have the same base class (so it is like a cheap multiple inheritance).

Another example might be when you load plugins - you could force all user created plugins to inherit from your plugin class, but that can get ugly if they have their own inheritance chain already. So you just require them to have something like Load(), Unload(), and Run() methods. After that you have no idea what they do, but that is all you need to know. Then when you use a plugin, you limit yourself to just using those methods, which helps keep things segmented and clean.

Just for a third example, say you have 'commands' in your program, they can 'do' and 'undo'. So you can have an ICommand interface that requires 'Execute()' and 'Unexecute()' methods. Then you can save all the commands that have been run in a list, and to undo or redo is just a matter of going up or down the list calling the appropriate methods. The good part is existing code can be turned into a command by just adding those two methods and the interface (implementing the interface).

A second use it when you have things that really actually need multiple inheritance. Maybe you have an animation that also behaves like a button sometimes, but you really can't make it a button because it is also a Movie. You can't make it inherit from both, sometimes composition isn't going to work either, so you use interfaces. The nice thing is when you pass it to a method that takes an IAnimation, the method sees it only as an animation. Then you pass the same object to a method that takes an IButton, and it sees it only as a button.

That should fog things up ; ).




Re: XNA Game Studio Express Interfaces

XNA-Mordt

Thanks for the explanation parlance.

Ok, so if an Interface only contains a specification for a class and the class has the methods specified in the Interface, if multiple classes used inherit from the same Interface wouldn't you need two sets of methods

Wouldn't it be better to just place the specification directly in the classes incase you need to change something later or use class Inheritance instead which seems much more logical to me or is class inheritance too restrictive

I'll have to take a look at the Game Services you mention.






Re: XNA Game Studio Express Interfaces

XNA-Mordt

That helped very much Robin, thank you. So could you basically have multiple Interfaces and theortically change a classes behaviour or rather add to a classes behaviour dependant on your current needs




Re: XNA Game Studio Express Interfaces

parlance

What an interface actually consists of is a full class definition, minus any of the method bodies (ie. Just the method prototypes and member definitions). Each class that inherits from the interface has to provide it's own implementation for the methods in the interface.

The key difference here between general class inheritance and implementing an interface is that the interface doesn't provide an implementation, which in some cases makes the most sense. Every class that implements an interface is required to provide a body for the functions in the interface whereas in general class inheritance, over-riding methods is optional.

Referring to my earlier example where an interface might be used to specify a physics engine interface which could be used as a game service, it wouldn't make much sense if instead a base class was used instead of an interface because the base class in this case wouldn't have any code, nor could it guarantee that any class that derives from it actually fulfills the intended functionality.

Part of what you need to understand when implementing an interface is that the interface should be designed so the implementation of the functionality intended to be provided is independant of the interface. It isn't necesary to 'place the specification directly into the classes so you can change something' because nothing is preventing you from using as many supporting methods as you'd like in addition to the methods that were implemented from the interface. The interface stays the same to guarantee interopability between code that uses any class that implements that interface.

Hope this helps.





Re: XNA Game Studio Express Interfaces

Robin Debreuil

Yeah, you can sort of think of interfaces as behaviour categories (that aren't tied to any specific group of objects). The category could still be big, so like Parlance mentions, you could use it to represent a whole physics engine and replace it with a completely different version if it implements the same interface. Most interfaces tends to be a few methods and properties, but it depends on your needs...

You do still have to implement the functionality in each class. Some languages allow you to actually inherit code from multiple parents (like Eiffel), but in this case you have to implement the code yourself. Of course you can still implement the interface in a base class of a paticular group so it covers several classes -- just you can't add code to an interface.

So to really stretch a metaphor, thinking of dogs and cats they could both have the IRollover interface. Teaching a dog to roll over is fairly simple, teaching the cat might require some electricity, so the code will be unique for each. However, most dogs can be taught the trick the same way, so that code could be in the Dog class rather than reimplemented for Poodle, Husky etc. -- which means you don't have to type it in for each class, just you can't put it in the interface. Meanwhile, they both can inherit from Animal, which by and large isn't capable of doing tricks like that, so it wouldn't want to inherit from Rollover.

Whew, I feel dirty after that one, I'm going to go wash my hands.




Re: XNA Game Studio Express Interfaces

XNA-Mordt

Thank you Parlance, I didn't notice your second post before replying to Robins. That description hits it on the head for me . I think I almost have it. I'm going to work on a few examples to see them in action now I understand why.

Thank you both.






Re: XNA Game Studio Express Interfaces

jpantuso

If you want an example of an interface with an detailed explanation of it you can look at the IGameDaemon interface here: http://developer.traygames.com/Docs/ doc=quickstart&page=tutorial_server

The idea is that we needed a consistent way for people to write a game daemon so that their server logic could be plugged into our back end. In order for that to work there is a very specific set of things we need to have implemented for communication between the game server logic and the back end server that manages it, an 'interface' if you will :-)

You can see how this would also be the case for things like a game object that will display itself to the screen, you would want a specific set of interfaces between the game object and the system responsible for talking to it, or a physics system might need an interface to objects to get details about their physical characteristics and deliver back movement etc. Making people implement an Interface is a nice way to combine clear communication of the requirement along with compiler directed enforcement.