[.net] C# Interfaces, do I really need them?

There are plenty of times when you will need interfaces, or when interfaces are simply the most elegant solution. They aren't really specific to laying out a contract for other developers to follow. Sure, they can be extremely helpful in doing that, but there are so many things that you can do with them that they are definitely worth learning about.

Interfaces are part of what the language has to offer, so I guess it's important to master a language with all its features. Some you might use more often, some less.

Interfaces are quite handy when you want to leave room for future, different implementations. Interfaces are "contracts" to which classes have to abide by; With interfaces you know that object will "fit" exactly in the place of another.

An example: let's say you want to load some data. At first, you think databases are the best thing in the world, and you go straight to implement a class which will help you load data from the db.

Upon second thought, though, you realize databases are overkill, and favour either plain text or xml.

However, now all you code is tied to the implementation of the previous loader. If you had used an interface, you could have simply implemented the new loader class, maintaining all the surrounding code the way it was.

Moreover, C# doesn't support multiple inheritance, whereas multiple interfaces are allowed.

Hope this helps!

Interfaces are a great tool to keep you OM clean and easy to extend. So if you aren't planning on others (including yourself) writing extensions for your projects there is really no need to do them.

They are also very usefull if you are communicating across tiers (server/client etc) or are integrating with legacy code.

But for small selfcontained projects it often does not pay out creating any interfaces.

To add to the scenarios people have mentioned, they're also very useful for unit testing purposes. If your object refers to the objects that it interacts with by interface rather than by concrete class, then it's possible for you to implement those interfaces using "mock objects" - fake objects that exist only for testing purposes - and then to test the object in isolation.

Thank you so much for your answers

Now I can conclude that:

there is a 90% probability that I wont be "needing" interfaces in the actual implementation of my game

It will be better for myself if I learn interfaces , so I will know what to do when it rains


Thanks!

You are very wrong good sir. Consider, for a moment, a game in which you have a bunch of resources that your game will need. Furthermore, some of these resources need to be reset whenever the graphics device is lost.

Now, do you want to do this:



Or do you want to do this:



Interfaces will be common in large majority of the applications you write. Even if you aren't writing your own, you will want to know how they work so you can take advantage of built in interfaces, which include the extremely important IDisposable.

Interesting read Mike

but I could also implement a Resource class that has an abstract method

void Reset()

every resource type then inherits from this class and so then I just could write


foreach (Resource res in MyResources)
{
res.Reset();
}

correct me if Im wrong

Regards

C# doesn't support multiple inheritence so if you inherit from an abstract class that exposes a Reset function, you can't inherit from any other classes. You can build a class that uses many interfaces though.

oh yes thats true

nice point

Im actually figuring out that I maybe will need interfaces in this project afterall

A carpenter never asks, "how am I ever going to use this stupid hammer?" He learns all tools, and when the job requires, he uses the most appropriate tool.

seems that carpenters have all the time in the world to do that

lucky bastards!

:)

Why can't you stop working on your project and make time to learn something? Why should it be a rainy day job?

They don't have all the time in the world, to become a good carpenter takes years, it's the same with programming (generally) but there are some basics that they have to learn before they can even call themselves carpenters.

*watches something fly over Ging's head*

Interfaces can be incredibly useful in C#. Its nice to be able to just trim down to a very unspecific collection of properties/methods instead of relying on the implementation. For example, I have a TextureAtlas class which takes in a bunch of graphics, builds the atlas, then tells them how to modify themselves to fit in the atlas. This could, and was done by just passing the base class to my graphics system. Though I realized how incredibly annoying it'd be to use in another project if I didn't use the same graphics system there, so I just made an interface that could get the Texture2D, a rectangle for the source in that Texture2D, and a method that allowed me to notify the graphic object that the atlas was assigning it a new value. Now I can attach it to just about any kind of graphic format I create as long as it has a source rectangle and a Texture2D.

Has it been useful thus far? No, not a whole lot, though it is a lot easier to maintain when you cut the dependencies down. But will it be useful in the future? Definitely. Even if I use a completely different graphics system, without copying any code I can get the graphics to make use of the atlas again in less than a minute. Or, better yet, since all my graphic items inherit from an ISprite interface, if I were to store a list of ISprites to support multiple drawing formats, I could atlas just where possible by:



No making things messy and trying to keep multiple lists. All my ISprites draw and update, and on the higher-end of things, thats all I care about so theres no need to get any more specific.