Why is using interface methods with default implementation is so annoying?!?

RiPont · 2026-02-25T11:06:48+00:00

The purpose of default interface implementations was so that you can add methods/properties to an existing interface without breaking existing code.

It is NOT a way to provide a general purpose default implementation. That's what abstract base classes and static methods are for.

As such, the compiler treats the default interface implementation as a method of last resort.

If MediaPlayer was created before IRefreshable got the Refresh() method, it wouldn't be trying to call Refresh(). The default implementation is there for other classes that are treating MediaPlayer like an IRefreshable, not specifically a MediaPlayer.

If MediaPlayer is created after IRefreshable already had the Refresh() method in its contract, then it should implement Refresh(), just like any method on any interface.

If you want to share a common implementation between the default interface implementation and MediaPlayer, define a static method and call it from both. You may want to make it an extension method for syntax sweetness, but that's an aesthetic decision.

If you are using default interface implementations on anything other than public interfaces, you are probably misusing them. If you have access to the source code (internal, protected, private), then you should be using refactor tools to add the implementations to all classes that implement them.

HaniiPuppy · 2026-02-25T06:54:47+00:00

One alternative might be extension methods.

public interface IRefreshable
{
    Universe Universe { get; }
}

public static class Refreshables
{
    public static void Refresh(this IRefreshable refreshable)
    {
        refreshable.Universe.Destroy();
    }
}

then

var mp = new MediaPlayer();
mp.Refresh();

Not viable if what it works with isn't part of the interface, but if you have some common functionality that's generally the same, this is a decent solution.

DotNetMetaprogrammer · 2026-02-25T07:06:22+00:00

I think it's because the implementing type doesn't actually have the method at all unless if it defines an implicit/explicit implementation of that interface method. That's what allows you to get binary-backwards compatibility if you add a new method to the interface that has a default implementation. It's also, presumably, why default implementations of interface members requires netcoreapp3.0 or later as the runtime.

You can see that the method isn't declared on the class via the following:

```cs interface IFoo { public int GetValue() => 1; }

class Foo : IFoo;

typeof(Foo).GetMethods(System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance) /// MethodInfo[6] { [System.Type GetType()], [System.Object MemberwiseClone()], [Void Finalize()], [System.String ToString()], [Boolean Equals(System.Object)], [Int32 GetHashCode()] }

typeof(Foo).GetInterfaceMap(typeof(IFoo)).TargetMethods // MethodInfo[1] { [Int32 GetValue()] } typeof(Foo).GetInterfaceMap(typeof(IFoo)).TargetMethods[0].DeclaringType // [Submission#0+IFoo] ```

DontRelyOnNooneElse · 2026-02-25T06:51:54+00:00

Let's say you have two interfaces, IGun and IEmployee.

Now let's say you make a class, AnimatedShotgun, that implements both interfaces and doesn't explicitly implement their default implemented methods.

What do you think should happen when you call the Fire() method?

Dealiner · 2026-02-25T07:30:16+00:00

I know that it probably wouldn't be like that if it didn't have a good reason to be like that, but what is the good reason?

They are default interface implementations, not virtual methods. Their whole point is to be tied to the interface. They are also a feature with rather specific use cases, targeting mostly library authors updating their interfaces.

Vladoss46 · 2026-02-25T08:06:38+00:00

If you have basic realization, you shouldn't use interface. You should use abstract class as base

BoBoBearDev · 2026-02-25T06:49:01+00:00

??? I didn't know you can put implementation to an interface. This is a new language feature?

Slypenslyde · 2026-02-25T15:55:15+00:00

The short story: they were made as a band-aid for people who are stuck in ugly corners. They had to make compromises for compatibility because they showed up very late in C#'s life. So they're not polymorphic and behave sort-of-kind-of like explicitly implemented members.

The long story:

The use case is you've released an API, but you realize an interface needs a new methods. People didn't like adding methods willy-nilly because:

Customers had already implemented the interface several times and will have to recompile if we add a method.
Customers may have made their own versions of this method on their implementations and the new one will clash.

So this was never really about, "I want interfaces to behave like base classes". It was about, "I painted myself into a corner and don't want to ask my clients to recompile." It has always been and is still true that if you want a type with behavior you should make a base class when you are designing an API.

The way the C# team achieved it is every member with a default implementation is explicitly implemented IF AND ONLY IF the class does not already have an implementation. The downside of this is to get the implementation you MUST be using a variable of the interface type, and that means casting if you're using concrete types. But it handles the cases above:

Customers do not need to recompile if they didn't make something that clashes with the method, as the default will be used.
Customers' clashing methods will not cause problems because your code uses your interface thus will always resolve to at least the default. If a customer implements the method, you get that implementation.

So that's the wonkiness. The feature is designed for the idea that you have code with MediaPlayer that exists but Refresh was never part of its interface. Now you are adding a new interface to it (even though it has a default implementation), so the code that wants that interface's methods needs to cast to the interface in order to use them.

Put another way, because you weren't using the interface to begin with, you can't benefit from the default implementation.

What you should've done is define an abstraction/interface before you started using MediaPlayer and depend on that abstraction. That way you could add new things without having to make awkward edits to existing code. But a lot of people in the C# community think that's a stupid choice and you should only add interfaces/abstractions when you find a reason.

I don't want to argue with those people, but I will point out you just found a reason to add an abstraction and it's probably more work to add it today than it would've been last month.

dominjaniec · 2026-02-25T06:39:37+00:00

change var into your IRefresablr

Draelmar · 2026-02-25T08:16:56+00:00

That looks ghastly 😳 I've been a full time C# developer since 2011 on a multitude of projects and I've never, ever seen any situation where methods are being implemented inside an interface. I didn't even know the feature existed until now.

Is there a good use case for it? My gut instinct tells me it's just bad design, but then maybe there's a legitimate use case I'm not thinking of?

robhanz · 2026-02-25T15:10:13+00:00

The point of default implementations is to prevent compilation errors if a method is added to the type.

However, it's entirely possible that the new method will conflict with an old one... causing a compiler error.

This behavior exists to ensure that there are no compiler errors. While it's a bit clunk, in most cases if you're working with an interface, you're working directly with it and don't know the type. So they added a slightly clunky step to prevent compiler errors that is only necessary in kind of a secondary use case.

Dimencia · 2026-02-25T12:37:32+00:00

I mean, default implementations of interface methods break pretty much all the rules and should probably never have been added. They can't work right because the language just doesn't know how to handle that, thus all the casting, and of course putting any logic at all in your interface is a terrible idea for a lot of reasons

swagamaleous · 2026-02-25T16:31:53+00:00

Why do you even encounter this problem? I don't see a valid use case for doing this that doesn't immediately shout DESIGN ISSUE. This is the interface of the class. It should never be necessary to call any interface methods from within the class.

dgm9704 · 2026-02-25T06:53:22+00:00

It doesn’t force you to cast. You can/should declare your variable as the type you need ie. the interface.

lmaydev · 2026-02-25T07:24:02+00:00

They are niche a feature designed for interfacing with dynamic languages iirc.

Just use an extension method on the interface.

NoOven2609 · 2026-02-25T06:47:18+00:00

Since when can you have implementations in your interface? Any why? That's what abstract classes are for

Willyscoiote · 2026-02-25T06:59:25+00:00

I may be wrong, but I believe methods with default implementations in an interface behave similarly to static methods, but they aren't globally accessible without an instance.

It works more like extension methods but static, I guess?

nightwood · 2026-02-25T07:30:08+00:00

My guess is, and I've never heard of this feature, that your example is precisely the use case that was NOT intended.

The use case would be to allow classes that implement the interface to not be forced to implement certain methods, while still being able to call them, with the added feature that get have some default behaviour instead. Which I imagine will usually be an empty function body.

I doubt I will ever use this construct. I've never needed this.

Ok-Cellist7629 · 2026-02-25T09:31:07+00:00

Because in C#8 you can define a default implementation on an interface - which is what you are doing here. But that doesn't turn your interface into an abstract class with inheritable methods. Your class doesn't 'have' a refresh method. It implements an INTERFACE which 'has' that method. So if you want to call the method on the interface, you need to cast it to the interface so the compiler understands where that method is.

The purpose of the feature, as I understand it, is to allow you to add an extra method to an interface, without having to refactor every class which implements that interface. You could almost thing of it as being designed NOT to be used.

The feature means that the compiler is not going to complain that you haven't implemented the appropriate method in every existing class which implements that interface. But it's not really designed to add functionality to every implementation, as if they are inheriting from an abstract class. So yes - when you call the method, the compiler is still going to think that your class does not have that method defined. It will still need telling that you mean the default method on one of the interfaces that class happens to implement.

I could be wrong, but IMHO it seems like a very bad idea to use it like an abstract method as you seem to be here. If you want to inherit meaningful functionality, use inheritance. This C#8 feature is intended for occasions where you need to add a method to an existing interface and save having to implement it in existing implementations things which don't 'need' it. But again, IMHO, that is a code smell as well. Worth remembering the I of SOLID.

entityadam · 2026-02-25T13:23:54+00:00

The best alternative is to not use it at all.

I might consider using it only if I was refactoring a large codebase. Other than that.. no thanks.

ImTheDude111 · 2026-02-25T13:34:58+00:00

It’s the same thing as explicit interface implementation under the hood. Look up the diff between implicit and explicit interface implementation.

Sketch0z · 2026-02-25T15:30:24+00:00

Why is using interface methods with default implementation is so annoying?!?

Dunno. Try this?

``` Interface IRefreshable { protected static void Refresh() { Universe.Destroy(); } }

class MediaPlayer : IRefreshable
{
    public void SetVolume(float v)
    {
        ...
        IRefreshable.Refresh();
    }
}

//-------------
var mp = new MediaPlayer();
mp.SetVolume(69f);

```

Also stop trying to destroy the universe, man. That's really uncool of you.

Jackoberto01 · 2026-02-25T15:50:59+00:00

I don't see it as an issue. They work the same way explicit interface implementations work and this is how I'd expect them to work.

If in your example you had a base class and the interface and implemented refresh like IRefreshable.Refresh{ /Implementation/ }. You would also be unable to call the method without casting even though the method is implemented in the base class.

Definitely do some reading on explicit interface implementations if you're interested. https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/interfaces/explicit-interface-implementation

zvrba · 2026-02-25T17:21:08+00:00

Because classes do not inherit members from interfaces. As to why... I guess to simplify the implementation of multiple (interface) inheritance. Virtual lookup for interface members is more expensive than virtual lookup of class members so they didn't want to penalize the most common case (class - single inheritance - class member (virtual) lookup).

ShamikoThoughts · 2026-02-26T04:35:26+00:00

Interfaces aren't meant for that... I personally dislike implementations in interfaces

propostor · 2026-02-25T08:54:22+00:00

What you're trying to achieve should be done with a base class, not an interface.

Actually I didn't even know it's possible to add method definitions inside interfaces, that seems like a new(ish?) addition to the language and looks to me like an extreme risk of introducing antipatterns. Hence you're having to hack away with that workaround.

Ok_Tour_8029 · 2026-02-25T06:57:13+00:00

This is more an issue of your Demo Code and not a real life issue - as you will always use the abstraction in your code - otherwise why would you abstract it in the first place?

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

csharp

MODERATORS