Interfaces

Contracts, not families

Inheritance models families: a Manager is an Employee. But many things share a capability without being related at all. A Document, a Photo and an Invoice can all be printed; a Bird, a Plane and a Drone can all fly.

An interface describes a capability as a contract: "any type that implements me provides these members".

interface IPrintable
{
    string Title { get; }
    void Print();
}

By convention, interface names start with I. Members have no access modifier — they're public by definition — and usually no body.

Implementing an interface

class Invoice : IPrintable
{
    public string Title => $"Invoice #{Number}";
    public int Number { get; init; }
 
    public void Print() => Console.WriteLine($"Printing {Title}...");
}
 
class Photo : IPrintable
{
    public string Title { get; init; } = "Untitled";
    public void Print() => Console.WriteLine($"Printing photo '{Title}' in color");
}

If a class forgets a member, the compiler reports an error — the contract is enforced.

Programming against the interface

The real power: code that uses the capability doesn't care what the concrete type is.

void PrintAll(IEnumerable<IPrintable> items)
{
    foreach (var item in items)
        item.Print();
}
 
PrintAll(new IPrintable[] { new Invoice { Number = 42 }, new Photo { Title = "Beach" } });

PrintAll will work with types that don't even exist yet. This idea — depend on abstractions, not concrete classes — is everywhere in professional .NET code: dependency injection, unit testing with fake implementations, plugins.

interface IEmailSender
{
    void Send(string to, string subject, string body);
}
 
class OrderService
{
    private readonly IEmailSender email;
    public OrderService(IEmailSender email) => this.email = email;   // real sender or a test fake
}

Several interfaces at once

A class has only one base class, but can implement any number of interfaces:

class Duck : Animal, IFlyable, ISwimmable
{
    public void Fly() { ... }
    public void Swim() { ... }
}

Interfaces you'll use constantly

For example, implementing IComparable<T> lets Array.Sort and List.Sort order your objects:

class Player : IComparable<Player>
{
    public string Name { get; init; } = "";
    public int Score { get; init; }
 
    // negative: this comes first; positive: other comes first; 0: equal
    public int CompareTo(Player? other) => other is null ? 1 : other.Score.CompareTo(Score);
}

Interface or abstract class?

Try it

Key takeaways

• An interface is a contract of members that implementing types must provide.
• A class can implement many interfaces but inherit from only one class.
• Use interface types for parameters and fields to keep code flexible and testable.
• Interfaces describe capabilities; abstract classes describe families with shared state.