How to define a function inside an Interface?

Let's say I have this interface:

public interface IHealth

{

    int health { get; set; }



    void TakeDamge(int amount);

}

And the definition of the function would be like this:

void TakeDamage(int amount)

 {

      health -= amount;

 }

Now, let's say that every object that implements that interface will have the exact same behaviour, aka the exact definition of the function. I can't define a function inside the main interface and also keep writing the exact same code of the function everytime I create a class that implements it is very redundant. Then where should I define that function?
The only thing that I can think of is creating a middle class the implements that interface and have my other objects inherit from that class. I don't know if there is a way to extend an interface.

 

Hello,
you can inherit from interfaces in c#, the same way you inherit from classes. The only caveat is that you MUST implement the methods otherwise it will throw an error.

 

You can add default implementations to interfaces in C#8. Unity isn't using C#8 though.

You could define a class and use inheritance, or you could use extension methods. Extending an interface with extension methods is quite a popular way of solving this problem.

 

Thank you for answering my question. Could you give me a code example of how to extend an interface? I tried googling it but nothing showed up. I searched for "unity extend interface"

 

As a general rule, what you're asking for suggests a design mistake. Interfaces represent a set of actions an object can take without opinion about how to complete those actions.

My question to you is, why will you need multiple classes all with the particular implementation of your TakeDamage you showed? One class that implements TakeDamage in this way should be enough.

 

I have different types of units with different behaviours and attributes, but they all share the functionality of taking damage. As I mentioned above one way I thought of approaching this is by creating a class that just implements that protocol only and have my other classes inherit from that class. But then I would be mixing class inheritance with interface implementation and I'm not sure if it's good or bad.

 

I will nit pick a little bit because I think you are confusing two closely related ideas.

You don't inherit an interface, you implement it.

You are looking for code reuse, that's great. Inheritance is one way to get code reuse, but there is another great option which is probably a better fit for what you are doing here.

So I don't put words in your mouth, why don't you give two examples of classes which might implement your TakeDamage method in exactly the same way. You probably don't need to show them, just give two class names.

 

It's actually a supported feature in recent C# versions like already mentioned. Probably inspired by Java, which allows this as well for quite a long time.

One alternative to using inheritance is composition, perhaps that's what @eisenpony was about to suggest next.

Like mentioned, recent versions allow default implementations, so there's surely some good use cases for them.
However, in your particular case it does only make things worse, because it requires to have a public setter for Health, which sort of renders the interface useless.

 

Since we seem to have missed our chance to discuss in realtime .. and @Suddoha stole my thunder ;p

I believe you are missing an opportunity to use composition in the design of your units. I'll encourage you to check out this old thread on interfaces and inheritance because I believe it deals with precisely the confusion you are hitting. It's a bit long, but I'm confident it will clear things up quite a bit for you.

To me, this is like suggesting a novice remove the guard from a circular saw to accomplish something that should be done with a jigsaw. Yes, it can be done and there are reasons the guard can be removed. However, it should be considered the exception to the rule. As I get more experienced, I find it is the things I learn to not do rather than the things I learn I can do which help me achieve my long term goals.

 

True. Personally I've never missed such a feature and I'm not looking forward to using it either. The example demonstrates one of multiple reasons why it's not as convenient as it seems.

 

A note: what you're asking for is no big deal in general (adding a default implementation to an interface). C# doesn't have it, but other languages do -- C++ and scala (super-Java) that I know of -- and it's fine and useful.

I believe C# didn't allow it at first (it's in version 8?) because it was a little more complicated with how C# works and .NET, they were busy with other stuff, and it's not that important a feature. That's the official answer to many "Why doesn't C# have X" questions.

 

I didn't spot the design issue precisely because a previous job I had was working in Java for Android apps and we had A LOT of interfaces. Like, dozens. I got used to see them here and there, but in Unity the design usually makes them less practical than other solutions.

 

Google c# extension methods. It's not part of Unity, its a c# thing.

 

Naraku?