koobas.hobune.stream
What's the use of abstract classes and interfaces in a game?
Hey guys, what's up? I was studying about Abstract Classes and Interfaces recently. Ok, I know how to use and the sintax in C#, but I really don't know in what it could be used, talking about games. To understand something, I guess we need to know his applications, and that's a point that I couldn't reach with this two things. Someone could give some examples? I don't need any type of code or something, just some kind of example of use.
Thanks from now! Hope this kind of question is permitted here in UnityAnswers, and sorry if it is not.
Cheers!
Yeah, sounds like a forum question to me. There is no clear answer to this. You could mark it as community wiki, but unlike Stack Overflow, we have a companion forum, so I would just recommend the forum.
Thanks for the 2 replies. I really liked your explanation kromenak. Turned the things more clear now!
Sorry for the newbie question, but, if I want to use something from a abstract class in my game I need at least 3 classes? One for the abstract, other for the implementation of the abstract methods and another in order to be able to instantiate this new script with the implemented methods or there's a easier way? Sorry if the question's a bit confusing. I'll explain better if you guys don't understand it.
Thanks from now!
Yeah, you will probably need at least three classes, as you said. In that third script where you instantiate, you'll just need to either "new" the subclass or do AddComponent if it is a monobehavior.
Unless the abstract class inherits from $$anonymous$$onoBehavior. ;) Then, when you inherit from it, the child class can become the script.
I also like your description, kromenak. You've pointed out a lot of the classical ideas behind polymorphism and inheritance. The only thing I have to add is that another difference between interfaces and abstract classes in C# is that, unlike C++ for example, C# doesn't support multiple inheritance. This means that if you want to bind your class to multiple contracts, you need to use interfaces ins$$anonymous$$d of abstract classes, because you can inherit from just one class at a time, but you can implement an arbitrary amount of interfaces. In the case of a weapon, you might split method declarations for methods that reload the weapon and methods that fire the weapon into two different interfaces. Then you can implement a child class that fires and reloads (implements both the IFirable and IReloadable interfaces), and another child class that fires, but doesn't reload. That could be a machine gun and a grenade, for example. (It doesn't really make sense to "reload" a grenade).
Using abstract classes and interfaces in games is much the same as using them in other applications. They allow for convenience and simplification when used correctly, but they can also silently add unneeded complexity.
Abstract classes and interfaces can be pretty similar, but they also have differences. An abstract class can actually have functionality in it, which child classes take advantage of. An interface only acts as a contract for the functions in a class, so no functionality in interfaces at all.
In our game, we use abstract classes when we have multiple items that share some base functionality, but that base functionality is not enough to be an object itself. For example, a Weapon class can contain functionality that is common to a crossbow and shotgun, but an instance of the Weapon class is pretty useless by itself - so making it abstract might be a good idea.
Interfaces are useful when you want to refer to several disparate objects by a common attribute - this makes it possible to put things into lists and iterate through them, even if they are very different classes. For example, a Robot and a Crate are very different objects in a game, but if both implement a Breakable interface, they can be considered equal objects, at least in the respect that they are both breakable. You can then define a
List Breakable
for example, and keep track of a lot of breakable things.
I say, as far as possible,split your codes to bunch of components. For example suppose you need the reload function. You know that all of weapons need to reload so you write an abstract class "weaponsystem" and an abstract method reload,then you write several classes(S$$anonymous$$G,A$$anonymous$$47,$$anonymous$$16,G3) that implement the reload function.it is cool but suppose that G3 and A$$anonymous$$47 have the same reload function but $$anonymous$$16 and S$$anonymous$$G have the same one. what to do. You need to copy and paste reload codes for G3 and A$$anonymous$$47 (and $$anonymous$$16 and S$$anonymous$$G). It is not bad? surely it is bad and causes problems. now suppose you write an interface IReloadable and implement it in Reload1 and Reload2 class. So you can use Reload1 for S$$anonymous$$G and $$anonymous$$16 class and Reload2 for A$$anonymous$$47 and G3 easily. Component based procedures give you a power you can easily extend your codes and programs. Use abstract class or common class for inheritence only when you are sure you need them.
an abstract class is the best way to remove duplication of extra code and restrict the user from creating its instance. I think @kromenak explained it very well.
