DEV Community: Aleksei Ananev

Default Interface Implementations in C#: Where Inheritance Goes to Troll You

Aleksei Ananev — Mon, 09 Dec 2024 20:40:10 +0000

Introduction

C# is a powerful and ever-evolving programming language, loved by developers for its robustness and versatility. With each new version, it introduces features that enhance convenience and streamline development.

However, much like Peter Parker, developers must wield this power responsibly. One slip-up, and you might find yourself tangled in a web of bugs and confusion.

A prime example of this is Default Interface Implementations, introduced in C# 8.0. This feature allows developers to define methods with default implementations directly in interfaces. While it enables smoother API evolution by allowing methods to be added without breaking existing implementations and improves C#'s interoperation with platforms like Android (Java) and iOS (Swift), it also opens the door to subtle, hard-to-detect bugs, especially when combined with inheritance and dependency injection.

In this article, we’ll explore a seemingly straightforward scenario where Default Interface Implementations swing into action, only to deliver a surprise ending. This topic was inspired by a recent situation I encountered in my own practice, which highlighted how easily things can go awry. We’ll unravel the technical reasons behind this unexpected behavior and share tips to ensure your code doesn’t fall into the same trap.

A Simple Service

Let’s start with a basic example. Imagine you’re working on a service, MyService, that depends on an IFoo interface. Nothing fancy, just your standard DI setup:

public class MyService
{
    private readonly IFoo _foo;

    // Constructor with an injected service.
    public MyService(IFoo foo)
    {
        _foo = foo;
    }

    // A method that prints a value.
    public void PrintValue()
    {
        // Get the value.
        var value = _foo.GetValue();

        // Print the value.
        Console.WriteLine(value);
    }
}

The IFoo interface has a single method, GetValue, which includes a default implementation. Here’s how the interface and its implementation look:

public interface IFoo
{
    // A method declaration with a default implementation.
    string GetValue() => "IFoo";
}

// An implementation of the interface.
public class Foo : IFoo
{
    // Overriding the method.
    public string GetValue() => "Foo";
}

When you run this in your trusty unit test, everything works as expected:

[TestFixture]
public class FooTests
{
    [Test]
    public void GetValueMustReturnFoo()
    {
        // Create an instance of the service.
        var foo = new Foo();

        // Get the value.
        var value = foo.GetValue();

        // Ensure the value is correct and equal to "Foo".
        Assert.AreEqual("Foo", value);
    }
}

The test passes, confirming that Foo.GetValue() returns "Foo".

Finally, you use MyService in a console app. In reality, this is a common scenario where the service would typically be resolved from a Dependency Injection (DI) container, but for simplicity, let's use the console app to demonstrate the concept.

class Program
{
    static void Main(string[] args)
    {
        // Create an instance of `Foo`.
        var foo = new Foo();

        // Create an instance of `MyService` using the `Foo` instance.
        var service = new MyService(foo);

        // Execute the method to get an output.
        service.PrintValue();
    }
}

Running this program produces the expected output:

Foo

All is right in the world. Or so you think...

What Could Go Wrong?

Now, imagine someone on your team decides to refactor the Foo class by introducing a base class FooBase:

// Introduce a base class.
public class FooBase : IFoo
{
}

// Derive `Foo` from the base class.
public class Foo : FooBase
{
    // No other changes here.
    public string GetValue() => "Foo";
}

Seems harmless enough, right? Right?

You run the tests. They pass. You deploy to production, and then… SURPRISE! The output changes:

IFoo

Why Does This Happen?

When a type is loaded into the CLR, a method table is created and initialized. This table is used by the runtime to resolve method calls to the actual methods that will be executed. Think of it as a guide that tells the runtime which method to call based on the type and method signatures.

Before the base class was introduced, the class Foo directly implements the interface IFoo. In this case, the method table for Foo maps interface methods to the class’s implementation, as long as the method signatures match. So, when GetValue() is called on an instance of Foo, the runtime looks up the method in the Foo class and resolves it to the GetValue() method explicitly defined there.

Before

+---------------+      +--------------+
| IFoo.GetValue | ---> | Foo.GetValue | 
+---------------+      +--------------+

However, when you introduce a base class (FooBase) and derive Foo from it, things get interesting. Now, Foo no longer directly implements IFoo. Instead, it inherits from FooBase, which implements IFoo. The method table is updated accordingly, and the runtime resolves method calls based on the inheritance chain. This means it looks at FooBase's method table to resolve the call. But here’s the kicker: FooBase doesn’t implement GetValue(), so the runtime falls back to the default interface implementation from IFoo.

After

+---------------+      +--------------+
| IFoo.GetValue |      | Foo.GetValue | 
+---------------+      +--------------+ 
       ^  |            +------------------------------------+
       |  +----------> | FooBase.GetValue (not implemented) | 
       +--(default)--- +------------------------------------+

In simpler terms, when Foo inherits from FooBase, the method table no longer directly points to Foo.GetValue(). Since Foo no longer explicitly implements IFoo, the runtime defaults to the method in the interface, which might not be what you intended, leading to the unexpected "IFoo" value instead of "Foo".

How to Prevent This?

Don’t shoot yourself in the foot with Default Interface Implementations. Here’s how to use them wisely:

Understand the Behavior: Default methods are convenient, but they can be tricky when paired with inheritance.
Avoid Unnecessary Inheritance: Inheritance is powerful, but don’t overuse it. If you need shared logic, prefer composition over inheritance.
Explicitly Derive from the Interface: Even if you introduce a base class that implements an interface, the derived class should explicitly declare that it implements the interface itself and provide method overrides as necessary.

// Explicitly implement the interface
// Yes, even if the class is derived from `FooBase`, which implements `IFoo`.
public class Foo : FooBase, IFoo
{
    // Override the method.
    public string GetValue() => "Foo";
}

Test Through Interfaces: Modify tests to interact with the interface directly, rather than through a concrete class or var. This ensures that the behavior being tested aligns with the contract defined by the interface. Using var or directly referencing the concrete class can inadvertently bypass interface behavior, masking potential issues with default implementations or inheritance.

// The improved test: Interact through the interface.
[Test]
public void GetValueMustReturnFoo()
{
    // Create an instance of the service using the interface, not `var`.
    IFoo foo = new Foo();

    // Get the value.
    var value = foo.GetValue();

    // Ensure the value is correct and equal to "Foo".
    Assert.AreEqual("Foo", value);
}

Leverage Static Analysis Tools: Use tools like Roslyn analyzers (e.g. Roslyn Analyzers for C# or SonarAnalyzer for .NET) to catch risky patterns.
Document and Review Changes: Always document changes involving default methods and review them thoroughly.

Conclusion

Default Interface Implementations in C# are a double-edged sword. While they provide immense flexibility and streamline API evolution, they also introduce complexities that can catch even experienced developers off guard. As shown in this example, subtle changes in class hierarchies can lead to unexpected behaviors, often surfacing only in production.

To avoid such pitfalls, prioritize composition over inheritance to reduce unintended coupling and improve code maintainability. Always test through interfaces to ensure that your implementations behave correctly, independent of specific class hierarchies. Additionally, document changes meticulously to keep the team aligned and prevent surprises.

Default Interface Implementations may be powerful, but with a thoughtful approach, you can navigate their pitfalls and ensure that inheritance doesn’t troll you again.

Lazy Dependency Injection for Microsoft DI ServiceProvider

Aleksei Ananev — Sat, 30 Jan 2021 04:53:03 +0000

Dependency Injection is a powerful tool and standard for achieving quality code. However, this can adversely affect performance and memory consumption, as instances may be created that are not used for the current request.

The previous post detailed the problem and one solution that allows gracefully solving it without polluting your code. This solution is to use LazyProxy for IoC containers. The main idea is to substitute an object of the real type with a proxy. This proxy is a runtime generated type that implemented a specific interface T and called all members of this interface through Lazy<T>. Thus, the behavior changes as if Lazy<T> was injected instead of the T interface. Instances are created only on demand, but at the same time, the code remains clean.

Today I am happy to announce that LazyProxy became available for one more container. LazyProxy.ServiceProvider library allows lazy dependency injection for Microsoft's DI ServiceProvider.

Usage of this library is similar to already existing libraries LazyProxy.Unity and LazyProxy.Autofac.

Here is an example of how to use this library. Consider the following interface and implementation:

public interface IFoo
{
    void Bar();
}

public class Foo: IFoo
{
    public Foo() => Console.WriteLine("Ctor");
    public void Bar() => Console.WriteLine("Bar");
}

A lazy registration for this service can be added like this:

// Creating a service collection
var services = new ServiceCollection();

// Adding a lazy registration
services.AddLazyScoped<IMyService, MyService>();

// Building the service provider
var serviceProvider = services.BuildServiceProvider()

Consider the following usage of the registered service:

Console.WriteLine("Resolving the service...");
var foo = serviceProvider.GetService<IFoo>();

Console.WriteLine("Executing the 'Bar' method...");
foo.Bar();

The output:

Resolving the service...
Executing the 'Bar' method...
Ctor
Bar

As you can see from the output, the constructor is not called until the first call to method Bar is made.

The initiative and brilliant initial implementation of the LazyProxy.ServiceProvider library belong entirely to Carlos Mendible, for which I want to express gratitude and appreciation on behalf of the entire open-source community. Besides, Carlos has generously permitted to move the new repository alongside all other LazyProxy's repositories. That was a big step forward in the lazy dependency injection ideas.

GitHub Repositories

LazyProxy
LazyProxy.Autofac
LazyProxy.Unity
LazyProxy.ServiceProvider

Lazy Dependency Injection for .NET

Aleksei Ananev — Sat, 21 Nov 2020 01:54:57 +0000

Dependency Injection Problem

Dependency injection is an essential part of modern applications that allows getting clean, reusable, testable code. Loosely coupled code and the single responsibility principle are considered best practices. And that's exactly what dependency injection helps to achieve.

Along with the power and benefits of dependency injection, there is at least one problem that can be illustrated as follows.

Assume a service called MyService depends on ServiceA and ServiceB. The number of all nested dependencies is N for ServiceA and M for ServiceB:

All these services are registered in an IoC container by corresponding interfaces:

container
    .RegisterType<IMyService, MyService>()
    .RegisterType<IServiceA, ServiceA>()
    .RegisterType<IServiceB, ServiceB>()
    ...

The MyService service has the following implementation:

public class MyService : IMyService
{
    private readonly IServiceA _serviceA;
    private readonly IServiceB _serviceB;

    public MyService(IServiceA serviceA, IServiceB serviceB)
    {
        _serviceA = serviceA;
        _serviceB = serviceB;
    }

    public void DoWork(int value)
    {
        if (value < 42)
        {
            _serviceA.DoWork();
        }
        else
        {
            _serviceB.DoWork();
        }
    }
}

The DoWork method uses either ServiceA or ServiceB depending on the value parameter. The important thing is that the method does not simultaneously use both services, but only one of them.

Consider this example of using the MyService service:

public void MyMethod()
{
    // Using the container directly is for clarity only.
    var service = container.Resolve<IMyService>();
    service.DoWork(1);
}

In this case, only ServiceA needs to be used. However, when resolving MyService from the container, both ServiceA and ServiceB will be created as well as all other nested dependencies. Thus, instead of instantiating (1 + N) services, all (2 + N + M) are created.

The following example illustrates another case where only part of the dependencies is used:

public class MyService : IMyService
{
    private readonly IServiceA _serviceA;
    private readonly IServiceB _serviceB;

    public MyService(IServiceA serviceA, IServiceB serviceB)
    {
        _serviceA = serviceA;
        _serviceB = serviceB;
    }

    public void DoWorkA()
    {
        _serviceA.DoWork();
    }

    public void DoWorkB()
    {
        _serviceB.DoWork();
    }
}

When calling the DoWorkA method, only ServiceA is used. ServiceB is not needed in this case, but it was still created when the MyService service resolving from the container:

public void MyMethod()
{
    // Using the container directly is for clarity only.
    var service = container.Resolve<IMyService>();
    service.DoWorkA();
}

Of course, the examples given are too simple for real life and are given only for clarity. However, in practice, often, similar situations arise.

To summarize, the problem with dependency injection is that it creates multiple instances that are not even used when the method is called. It leads to:

Increased consumption of CPU time to create unused service instances. Especially important if for some reason there are slow constructors in those services.
Increased memory consumption due to allocation for unused service instances.
Decreased performance due to increased load on the garbage collector.

Solutions

This problem can be solved in several ways.

Singletons

The specified problem becomes negligible if the services are registered in an IoC container as singletons. In this case, the problem only affects the first resolution of the service. However, in many cases, making all services singletons is a rather problematic task, especially for legacy code.

More Dependencies

In some cases, the service can be divided into dependencies by reducing responsibility and methods. For instance, in the second example above, the DoWorkA method and the DoWorkB method could be divided into different services. But this approach may not always help, as can be seen from the first example above when the DoWork method uses a condition by value.

Fewer Dependencies

Sometimes, combining several services into one can reduce the depth of the dependency tree nesting. It is especially helpful when services are overly segregated. However, this can negatively impact code reusability and testability.

ServiceLocator

Instead of injecting services, some use different service locators. However, this is considered to be an anti-pattern that breaks encapsulation, so ideally you want to avoid it.

Inject Lazy<T> Instead of T

Using Lazy<T> rather than the T solves the indicated problem.

The implementation of the first example changes as follows:

public class MyService : IMyService
{
    private readonly Lazy<IServiceA> _serviceA;
    private readonly Lazy<IServiceB> _serviceB;

    public MyService(Lazy<IServiceA> serviceA, Lazy<IServiceB> serviceB)
    {
        _serviceA = serviceA;
        _serviceB = serviceB;
    }

    public void DoWork(int value)
    {
        if (value < 42)
        {
            _serviceA.Value.DoWork();
        }
        else
  {
            _serviceB.Value.DoWork();
        }
    }
}

In this case, two Lazy<T> instances are created when the MyService service is resolved. (1 + N) more services are resolved only when the DoWork method is executed with the value == 1 (as in the example above). In total, instead of (2 + N + M) created instances, only (3 + N) are created.

The difference is more significant, the more dependencies the MyService service has, and method branches use the more specific services.

The downside of this approach is that it pollutes the code with Lazy<T> and someServiceLazy.Value making it less readable.

LazyProxy

LazyProxy solves the above problem without requiring you to change your service code at all.

This library allows you to generate at runtime a type that implements a given interface and proxies all members of this interface to calls through Lazy<T>.

The following example shows how LazyProxy works.

Assume there is the following interface:

public interface IMyService
{
    void Foo();
}

Then a lazy proxy type can be generated this way:

var proxyType = LazyProxyBuilder.GetType<IMyService>();

The generated type looks like this:

// In reality, the implementation is a little more complicated,
// but the details are omitted for ease of understanding.
public class LazyProxyImpl_IMyService : IMyService
{
    private Lazy<IMyService> _service;

    public LazyProxyImpl_IMyService(Lazy<IMyService> service)
    {
        _service = service;
    }

    public void Foo() => _service.Value.Foo();
}

The generated type hides all of the boilerplate code of using Lazy<T>. So, LazyProxy can eliminate the main disadvantage of lazy injection but keep the main advantage.

LazyProxy Registration

Generating a proxy type at runtime is only half the battle. It is necessary to register this type in the container somehow and preserve the ability to resolve a real type when calling _service.Value. This can be achieved in several ways.

Named registrations

Named registrations can be used to register and resolve a real service. This method can only be used for containers that support named registrations.

Here is a simple example of how a proxy type and a real type can be registered in the Autofac container:

const string registrationName = "RealService";

// Creating a container builder.
var builder = new ContainerBuilder();

// Registering a type mapping for the real service.
builder
    .RegisterType<MyService>()
    .Named<IMyService>(registrationName);

// Registering a type mapping for the lazy proxy.
builder
    .Register(c =>
    {
        var context = c.Resolve<IComponentContext>();
        return LazyProxyBuilder.CreateInstance(
            () => context.ResolveNamed<IMyService>(registrationName));
    })
    .As<IMyService>();

// Building the container.
using var container = builder.Build();

// Resolving the lazy proxy.
var lazyProxy = container.Resolve<IMyService>();

Marker interface

Another way is generating an additional marker interface at runtime that will implement the main interface and be used to register and resolve a real service.

This method is a little more complicated to implement than named registrations, as it requires a runtime code generation. Simultaneously, this method is universal, as it can work for containers that do not support named registrations.

LazyProxy for IoC Containers

There are already ready-made libraries for some IoC containers that implement the described approach.

LazyProxy.Autofac

LazyProxy.Autofac implements lazy registrations for the Autofac container.

Here is an example of how to use this library:

var builder = new ContainerBuilder();
builder.RegisterLazy<IFoo, Foo>();
using var container = builder.Build();
var lazyProxy = container.Resolve<IFoo>();

LazyProxy.Unity

There is also an implementation for the Unity container named LazyProxy.Unity.

The syntax is similar to the previous example:

using var container = new UnityContainer();
container.RegisterLazy<IFoo, Foo>();
var lazyProxy = container.Resolve<IFoo>();

Conclusion

Dependency Injection is a powerful tool and standard for achieving quality code. However, it has the disadvantage that multiple instances are unnecessarily created. It negatively affects performance and memory consumption.

There are several solutions that you should use whenever possible to mitigate the negative impact of dependency injection.

One solution is using the Lazy<T> injection instead of T. However, such injection pollutes the code, so this use is not recommended.

Instead, it is suggested to use the LazyProxy library, which allows you to get lazy injection benefits while still getting clean code. This library can be used for various containers to register lazy dependencies. There are implementations for the Unity and the Autofac containers that allow you to simply register lazy dependencies.