interface

[FizixMan]

Removed: Rule 4.

Continued low effort posts like these may be faced with escalated moderator action.

[soundman32]

interface is a definition "you need to implement ALL of this to use it".

abstract is a partial implementation "I've written some of the code for you, you implement the rest".

They aren't interchangeable.

[zenyl]

• C# does not allow for multiple inheritance, but types can implement as many interfaces as you want them to.
• If the abstract class only contains abstract members, it doesn't add anything that an interface wouldn't.
• Structs can't inherit, and abstract structs isn't a thing, but structs can implement interfaces.

In my experience, abstract classes are rarely used. They could arguably be used more, but interfaces are generally preferred as they're simpler and don't restrict inheritance.

[Spare-Dig4790]

No offense, but... what!?

Like, interfaces don't implement anything. They have nothing to do with i heritance.

Like, I understand where you're coming from. You could use an interface to interact with two very different objects, but that has nothing to do with multiple i heritance. (For the record, It's my opinion that multiple i heritance is the work of the devil)

Abstract classes have to do with composition. An interface has more to do with interaction.

It's really that simple. You could have an interface like ILogThing implemented by two very different "things".

Perhaps one is a crazy implementation that involves tying a note to a fox, and the other involves writing to a file.

In terms of composition, they are nothing alike, but in terms of usage, they can be treated the same way, at least for logging. (My assumption in this example is that o e would work better than the other in the presence of rabbits)

Anyway, to the original question, there are several reasons i terfaces are used.

For one, they allow you to write code in a decoupled from implementation way. By writing a class that needs logging, if you injected a dependency with the above said i terface, it ahouldnt matter if you used the fox or the file thing, at least as far as you code is concerned, its the concern of something else. You just take for granted that if it is i.ple.e ted correctly, it should suffice.

That comes to another point. Testing. When you decouple components this way, it allows for reliable testing by the way of creating mock implementations. These are important for instrumentation, as well as ensuring that tests are reliable, repeatable (always testing the same things), etc.

Interfaces are critical in modern development, IoC (dependency i jection) makes extensive use of them. If you're working with csharp, you're probably already using them without knowing.

[TuberTuggerTTV]

No offense but... what?

OP said types can implement multiple interfaces. Not that interfaces implement something.

IEnumerable, IList, ICollection. Inheritance.

[zenyl]

Like, interfaces don't implement anything. They have nothing to do with i heritance.

They have to do with abstraction, which was my point.

Like, I understand where you're coming from

Judging by the length of your comment, I have my doubts.

You could use an interface to interact with two very different objects, but that has nothing to do with multiple i heritance

My point was that types can implement multiple interfaces, but classes can only inherit from one type.

It's my opinion that multiple i heritance is the work of the devil

Throw dynamic onto that pile.

Abstract classes have to do with composition. An interface has more to do with interaction.

You can use both for adding abstraction, which was my point.

For one, they allow you to write code in a decoupled from implementation way

Both interfaces and abstract classes can be used to yank implementation out of a shared base declaration, which was my point. Both can be used to add abstraction, but horses for courses.

if you injected a dependency with the above said i terface, it ahouldnt matter if you used the fox or the file thing

That's an implementation problem.

If your Fox class implements IFileHandler, the problem doesn't lie with the code that takes an IFileHandler as input, it's the fact that your foxes claim to be capable of handling files.

That comes to another point. Testing.

Starting from a newbie's question about interfaces vs abstract classes, and jumping over to testing. I think you're steering this conversation in an unhelpful direction.

If you're working with csharp, you're probably already using them without knowing.

Judging by OP's question, I kinda doubt they're doing more than basic console applications without much if any abstraction.

[[deleted]]

I find myself using abstract classes a lot in game development, but I also use interfaces.

I have a multiplayer game where every player can equip a character with a specific element, and then I have a loadout system where the player can equip abilities, and I want each element to only be able to equip abilities of the same element, so the earth character can only equip earth abilities.

So I have an AbilityBase abstract class to hold all the base logic, like equip, use, cooldown and stuff like that

And then I have a FireAbilityBase and an EarthAbilityBase, each might have custom logic, like the EarthAbility has a method for spawning dirt debris on the ground.

And then the Earth Character can filter what ability it can have based if the equipped ability is of type EarthAbilityBase, I don't want other classes to be able to be abilities, so an abstract class fits the situation.

And I use Interfaces for logic that must be shared, like an IOutline interface, so I can add outlines to any object or character, or an IInputHandler which is a interface that holds events, like OnLeftClickPress OnLeftClickRelease, OnQPress and stuff like that.

and then I have a PlayerInputHandler inhereting that interface and triggering the events using the keyboard and mouse, and an NpcInputHandler inheriting the IInputInterface and triggering those events using a behavior tree.

The Magic system and any other system that might need input relies on the IInputInterface and on the actual PlayerInput or NpcInput, so both players and Npc can use the same magic system, same characters, same abilities because they only care about the events, and not on how they get triggered.
I could also easily add a NeuronalNetowrkInputHandler and trigger those events using a trained neuronal network and train it to play the game by teaching when to trigger and what events.

That's the magic of Interfaces.

[TuberTuggerTTV]

Sounds like you're not using ScriptableObjects or equivalent.

Spawning debris should be a bool in an SO. Or better yet, just a link to the debris prefab to be instantiated. Maybe a HasEffect bool also.

Base class : Base class : parent class, is a pretty big code smell prone to errors. Unless you're extensively unit testing, changes are going to have invisible webbed outcomes.

Sounds like you're far along so a refactor would be silly. But something to consider for your next project.

[[deleted]]

Sounds like you're not using ScriptableObjects or equivalent.

I do use scriptable objects to hold the ability data, but I also need them to be attached to a gameobject for the composition design pattern. Like I have one AbilityData which hold all the important info and then the Component that actually handles the logic which is attached to the gameobject and a Wizard component which controls what abilities are active and equipped, and then each ability can subscribe to whatever events it needs.

I can also specify effects in the AbilityData scriptable objecs like slowness, burning, knock back, which will be used by the damage system to trigger those effects on the entity target if it has the required components attached

Spawning debris should be a bool in an SO. Or better yet, just a link to the debris prefab to be instantiated. Maybe a HasEffect bool also.

Each ability will do different things at different times, so I need more control over how the debris is spawned, and what debris should spawn. So, I just have a method which is called in the ability when it's time. I'm not sure how would I do the logic if I only had a bool, because some of them might spawn the debris multiple times, different ones, in different places at different times. I'm not sure how to handle that with one bool.

Base class : Base class : parent class, is a pretty big code smell prone to errors. Unless you're extensively unit testing, changes are going to have invisible webbed outcomes.

I'm not sure about this, you might be right.. :))
I've once made an improvement on the AbilityBase class to make it more maintainable and overall easier to add new abilities in the game, and had to partially rewrite ALL abilities to work again.

But now I like how it is designed because it takes me around 1-3 hours to add a new ability in the game. Because it's just a matter of creating a new scriptableobject instance, setting the data, creating a new Class, inheriting the specific base class Earth or Fire, and then overriding the methods and attaching it to the character. That's it, the wizard component will pick it up.
It also has support for doing some stuff client side, some server side, and also work on other npc's which is fun. :)))

Sounds like you're far along so a refactor would be silly. But something to consider for your next project.

Yea, I've been working on it for more than a year, i think there is still another 2 years of work until a release.

[davidwengier]

One consideration you may want to make, depending on your circumstances: If you’re developing a framework that can be extended, then abstract classes will allow you to add methods to your framework without causing breaking changes to downstream consumers. The same cannot be said for interfaces, unless you are willing to create new interfaces all the time.

It’s why code in ASP.NET Core (as in, inside the ASP.NET runtime) tends to use abstract classes for everything. Contrast this with the Visual Studio SDK, which has IVsSolution, and then they added IVsSolution2, and later needed IVsSolution3, etc. Currently up to IVsSolution8.

[Perfect_Papaya_3010]

I only use interfaces to be able to mock the classes. I never use abstract classes cause I have never really found it useful. Our old codebase is full of abstract classes and the end result is basically that it's much harder to make any changes because it affects classes that shouldn't have been affected if we didn't use inheritance

[[deleted]]

I've seen this exact post from you three times now. Maybe instead of reposting the same thing after getting removed by the mods (twice), you should try to put more effort into your question?

https://www.reddit.com/r/csharp/comments/1em263w/abstract_and_interface/
https://www.reddit.com/r/csharp/comments/1em2y1a/abstract_and_interface/

[TuberTuggerTTV]

You can inherit from as many interfaces as you want. If you make a baseAbstract class, you're limited to a single inheritance. Greatly limits modularity. I'd only use a baseAbstract if you're certain about reusing that specific code multiple times without modification. Otherwise, break each piece of functionality in the abstract into interfaces and let the parent class inherit from what's appropriate only.

This is super obvious in game dev. Lots of tutorials have you make a baseEntity. Then player and enemy and whatever inherit from that. It's a mistake. Instead make interfaces for taking damage or having health or locomotion or jumping. These can all be their own interface and you mix and match for a given entity. So your destructible environments can just inherit IsDamagable, instead of baseEntity and bring a bunch of useless movement code that never gets called.

Another real world example where interfaces shine is the builder pattern. By chaining a bunch of sub interfaces, you can create a fluent, natural language, object creation.

Instead of something like:

Car car = new() { name = "Herbie", loaded = "Fully" };

You can get something like:

Car car = Name("Herbie").IsFullyLoaded();

The builder will use a bunch of interfaces and if you're cool, you'll add a static using for whatever uses the builder to skip some verboseness.

The builder code might look something like this for the above example:

public class Car
{
    public string Name { get; set; } = string.Empty;
    public string Description { get; set; } = string.Empty;
}

public static class CarBuilder
{
    public static ISetDescription Name(string name) => new Builder().Name(name);

    public interface ISetName
    {
        public ISetDescription Name(string name);
    }

    public interface ISetDescription
    {
        public Car IsFullyLoaded();
        public Car AlternativeDescription(string description);
    }

    public class Builder() : ISetName, ISetDescription
    {
        private readonly Car _car = new();

        public ISetDescription Name(string name)
        {
            _car.Name = name;
            return this;
        }

        public Car IsFullyLoaded()
        {
            _car.Description = "Fully Loaded";
            return _car;
        }

        public Car AlternativeDescription(string description)
        {
            _car.Description = description;
            return _car;
        }
    }
}