Introduction

In C#, the difference between implicit and explicit interface implementation is mostly about API shape. Both satisfy the interface contract, but they change how callers reach the member and whether that member appears as part of the class's normal public surface.

Implicit Implementation Makes the Member Public on the Class

An implicit implementation is a normal public member whose signature matches the interface:

1public interface ILogger
2{
3    void Log(string message);
4}
5
6public class ConsoleLogger : ILogger
7{
8    public void Log(string message)
9    {
10        Console.WriteLine(message);
11    }
12}

That means both of these calls work:

1var logger = new ConsoleLogger();
2logger.Log("hello");
3
4ILogger asInterface = logger;
5asInterface.Log("hello");

The method is visible whether the object is treated as ConsoleLogger or as ILogger.

Explicit Implementation Hides the Member Behind the Interface

An explicit implementation names the interface as part of the member definition:

1public interface ILogger
2{
3    void Log(string message);
4}
5
6public class ConsoleLogger : ILogger
7{
8    void ILogger.Log(string message)
9    {
10        Console.WriteLine(message);
11    }
12}

Now the concrete type no longer exposes Log directly:

1var logger = new ConsoleLogger();
2// logger.Log("hello");   // does not compile
3
4ILogger asInterface = logger;
5asInterface.Log("hello");

This is the core idea: the member still exists, but only callers using the interface can see it.

When Explicit Implementation Helps

Explicit implementation is especially useful when two interfaces define the same member name and the class needs separate behavior for each one.

1public interface ITextWriter
2{
3    void Write(string value);
4}
5
6public interface IAuditWriter
7{
8    void Write(string value);
9}
10
11public class Writer : ITextWriter, IAuditWriter
12{
13    void ITextWriter.Write(string value) => Console.WriteLine($"TEXT: {value}");
14    void IAuditWriter.Write(string value) => Console.WriteLine($"AUDIT: {value}");
15}

Without explicit implementation, those two Write members would collide on the public class surface.

It is also useful when the interface member is technical plumbing rather than a feature you want most callers to discover first.

Choose Based on API Intent

If the interface member is part of the everyday meaning of the class, implicit implementation is usually the better fit. A logger should probably let callers say logger.Log(...) without casting.

If the member exists mainly to satisfy a framework, adapter, or niche interface contract, explicit implementation can keep the public API cleaner. That is why you often see it in framework integration code or classes implementing multiple related interfaces.

There is also a middle ground: a class can expose a public helper method for its normal API and still implement an interface member explicitly when the contract needs different naming or a more constrained call path. That is less common, but it is useful when the interface is not meant to define the whole public story of the type.

The design question is simple: should this operation feel like a normal capability of the concrete type, or should it appear only when the object is treated as the interface?

Common Pitfalls

The most common surprise is writing an explicit implementation and then forgetting that the method cannot be called through the concrete type.

Another pitfall is using implicit implementation when two interfaces have the same member signature but different meanings. That can force one public method to represent two different contracts poorly.

It is also possible to hide too much. If the method is central to how consumers use the class, explicit implementation can make the API awkward because callers must cast unnecessarily.

Summary

• Implicit implementation makes the interface member part of the class's visible public API.
• Explicit implementation exposes the member only through the interface type.
• Use implicit implementation when the member is a natural capability of the class.
• Use explicit implementation for interface collisions or interface-only behavior.
• The choice is about API design and discoverability, not about whether the interface contract is satisfied.