Interface Default Implementation in C#

How It’s Different from Abstract Classes

Interface Default Implementation : You might be thinking, "Wait, aren’t interfaces just a collection of method signatures without any implementation?" Normally, yes. But with C# 8.0, interfaces got a major upgrade. Now, they can have default implementations for methods. This new feature has added some flexibility to interfaces, but it also brings up a natural question: How is this different from abstract classes?

Let’s explore the reasons behind this addition, how it works, and what makes interface default implementations different from abstract classes.

---

What is Interface Default Implementation?

Historically, interfaces in C# were a way to define a contract without any implementation. They were essentially a list of method signatures that classes had to implement. But with interface default implementation, you can now provide a default body for methods directly within an interface. This means classes that implement the interface don’t have to provide their own implementations for these methods if they’re okay with the defaults.

Here’s a simple example to show you what it looks like:

📌Explore more at: https://dotnet-fullstack-dev.blogspot.com/

🌟 Restack would be appreciated! 🚀

public interface ILogger
{
    void Log(string message);

    // Default implementation
    void LogError(string errorMessage)
    {
        Log($"Error: {errorMessage}");
    }
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

// Usage
var logger = new ConsoleLogger();
logger.LogError("An unexpected error occurred.");

In this example, ILogger has a LogError method with a default implementation. Since ConsoleLogger only implements Log, it automatically inherits LogError from the interface. This is pretty cool, right?

---

Why Did C# Add Default Implementations to Interfaces?

There were a few key motivations behind this feature:

1. Backward Compatibility: As .NET grows, it’s important to evolve interfaces without breaking existing code. Adding a new method to an interface previously required updating every class that implemented it. With default implementations, we can add new methods to interfaces without forcing changes on all implementing classes.

2. Reusable Code: Sometimes, you want to provide a common implementation for a method across multiple classes. Interface default implementations allow you to add shared code directly within the interface itself, reducing repetition and improving maintainability.

3. Cleaner API Design: By allowing default behavior in interfaces, API designers can add functionality without disrupting existing users. This is especially helpful for frameworks and libraries.

Now that we’ve covered the “why,” let’s look at how interface default implementation compares to another familiar concept: abstract classes.

---

Interface Default Implementation vs. Abstract Classes

At first glance, interface default implementation might look a lot like what we do with abstract classes. Both allow us to provide default behavior that subclasses or implementing classes can override. So, what’s the real difference?

Let’s break it down.

1. Purpose and Intent

• Interface: The primary purpose of an interface is to define a contract. It specifies what actions a class can perform but not how. The default implementation is optional and is intended to provide a fallback or commonly used behavior, but it’s not the main focus.

• Abstract Class: An abstract class is a blueprint for derived classes. It’s intended to provide both a contract and some core functionality that subclasses must adhere to. Abstract classes are inherently closer to the implementation details of an object than interfaces.

Think of it this way: An interface with a default implementation is like a guide with helpful suggestions, while an abstract class is more like a template with specific rules.

2. Fields and State

• Interfaces: Interfaces still can’t have fields. You can’t store data in an interface, so you’re limited to methods without any state.

• Abstract Classes: Abstract classes can have fields, properties, and methods. They can maintain state, which is sometimes essential for the functionality they provide.

This difference is key because if your base functionality relies on internal data, an abstract class is your only choice. Default implementations in interfaces are typically lightweight and stateless.

3. Multiple Inheritance

• Interfaces: One of the main reasons interfaces exist is to allow multiple inheritance. A class can implement multiple interfaces, but it can only inherit from one class (abstract or otherwise).

• Abstract Classes: You can only inherit from one abstract class. If you need to extend multiple base types, abstract classes are limiting.

If your class needs to inherit behavior from multiple sources, interfaces with default implementations are a great choice since they allow flexibility that abstract classes can’t provide.

4. Binary Compatibility

• Interfaces: Default implementations in interfaces allow for backward compatibility. This means you can add new methods to an interface without breaking existing implementations.

• Abstract Classes: If you add a new abstract method to an abstract class, you’ll need to update every derived class to implement this new method.

This is especially important in frameworks and libraries that want to evolve their APIs without breaking users’ existing code.

5. Optional vs. Mandatory Implementation

• Interfaces: Default implementations in interfaces are optional. A class implementing the interface can choose to override the default behavior or use it as-is.

• Abstract Classes: If an abstract class defines an abstract method, every derived class must implement it. There’s no “default” to fall back on.

The optional nature of interface default implementations provides more flexibility for developers to choose which behavior to override.

---

When to Use Interface Default Implementations vs. Abstract Classes

With these differences in mind, let’s look at when to use each option.

Choose Interface Default Implementations when:

• You want to define a contract with optional, reusable methods that classes can override if needed.

• You need to maintain backward compatibility and don’t want to break existing implementations by adding new methods.

• You want to give implementing classes the freedom to use default behavior or provide their own.

Choose Abstract Classes when:

• You need to share state or data across methods.

• You have a set of methods that every subclass must implement.

• You’re designing a base class that serves as a foundation for specific types, rather than simply enforcing a contract.

---

A Practical Example: Logger Interface vs. Abstract Base Class

Let’s put this into perspective with a simple logging system. Say we have two requirements:

1. Every logger must have a Log() method.

2. We want an optional LogError() method that prepends “Error:” to the message if the implementing class doesn’t override it.

Using Interface Default Implementation

public interface ILogger
{
    void Log(string message);

    void LogError(string errorMessage)
    {
        Log($"Error: {errorMessage}");
    }
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

Here, ConsoleLogger doesn’t have to implement LogError() unless it wants custom behavior.

Using an Abstract Class

public abstract class BaseLogger
{
    public abstract void Log(string message);

    public virtual void LogError(string errorMessage)
    {
        Log($"Error: {errorMessage}");
    }
}

public class FileLogger : BaseLogger
{
    public override void Log(string message)
    {
        // Write message to a file
    }
}

In this case, FileLogger inherits LogError() but must implement Log(). If the logging system relied on shared fields or properties, BaseLogger would be necessary.

---

Wrapping Up

Interface default implementations give us a new, flexible tool for managing optional behavior in interfaces. They add a bit more versatility, but they don’t replace abstract classes. When choosing between them, consider your needs: Do you need multiple inheritance? Go with interfaces. Do you need shared state? Abstract classes are the way to go.

With these options at your disposal, you have the flexibility to structure your code in ways that are both powerful and clean. Happy coding, and remember: there’s no “one-size-fits-all” solution—only the best fit for your specific scenario!