Re: C#: abstract classes VS interfaces
Hi there,
speaking from conceptual point of view, you use abstract classes, when two classes share characteristics and work in similar way, whereas you use interfaces for two classes, which work differently, and you just need to use them in the same way.
For example, if you have a class Plane. This plane has some properties, such as Width, Height, Weight etc. All kinds of planes will have those characteristics, so it's okay to hold them in this class.
Now, if you want to create various kinds of planes, such as FirePlane, WarPlane, TravellingPlane, it's reasonable to make the class Plane abstract, and inherit it in the other classes. It's because all kinds of planes not just have those features such as Height, Weight etc. but they also work in the same way, because all of them are planes.
Now, let's say we were making an audio player. To be actually able to play an audio, we need an audio source, where we could get the actual audio from. But we don't know and even don't want to know how the audio source works inside. it could be a file stream, but also a stream from microphone, website, some encrypted container, or even speech synthesis generator or an ai music generator. Options are endless and in most cases they don't share any similarities with each other at all. The only thing they have in common is a GetFrame method, or something similar, which will return a piece of audio.
Thus it's reasonable to use an IAudioSource interface with such a method, so we can use it without worrying how is the audio actually created.
Btw, this is also the reason, why are interfaces so popular in dependency injecting and inverse of control. DI works exactly in their way - you don't program against implementations, but against interfaces. In other words, you don't instantiate classes in your class on your own, you just use interfaces with enumerated functions, which you need and let an implementation be injected.
If you use ioC, it is then possible to wire everything from one place, and switch various classes for example for mocking classes, but also classes with different functionalities, that fit best in particular time.
It is of course also possible to inject based on abstract classes, but because of the nature of di, interfaces are in many cases the preferred choice.
Another way, how to decide between an abstract class or interface is, that firstone will help you prevent redundant code whereas the secondone won't.
If two classes work in the same way i.e. you are writing almost the same code for each of them, it's the time to think about inheritance. if you find out, that inheritance is a good choice, then you use it and if the parrent doesn't itself make a sense to be instantiated, you mark it abstract.
I.E. both elephant and a cat are animals. They can do similar things, like walking, making a sound, etc. and have similar properties - number of legs, number of eyes etc. Some of the code such as making the sound will be specific for each of them, so we can't make a parent / children relationship between them, but some code, such as properties handling, will be definitely the same, so we make an Animal class, which will store the common code and its inheritors will just add their things. That's a normal inheritance. However, now, it doesn't really make a sense to instantiate the Animal class, especially taking in the fact, that some kinds of methods like Walking don't even have a common implementation. So we mark it abstract and just use it as a codebase or a reference point.
Interfaces can't do this. Infact, personally I don't even agree with taking interfaces as a form of inheritance. It's probably better in literature to have one common term instead of two, but it seems to me more like certifying rather than inheriting. A class don't inherit anything, but by implementing an interface, it's certified to be able to do certain things and to have certain properties.
In practice, both abstract classes and interfaces are equal, or at least from my experience. There are situations where you need one and situations, where you need the otherone, like there are dishes to be eaten with a fork and dishes to be eaten with a spoon. but you can always just grab the dish to your hands and eat it without any kind of cutlery or simply drink it, if it's a soup. It's completely upto you.
That's nice on the programming... unless you need to work with code of others.
Best regards
Rastislav
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
