C# Interfaces for Beginners: Contracts Explained

An interface is a contract — a promise that a class will do certain things, without saying how.

Imagine you're building a system that needs to print documents. You have a Document class, an Image class, and a Spreadsheet class. Each can be printed, but each prints differently. You want a single method Print() that works on any of them, without caring about the specific type.

In C#, you can define an interface — a list of method signatures — and have each class implement that interface. Then you can write code that works with the interface, and it will work with any class that implements it. This is one of the most powerful tools for building flexible, maintainable, and testable applications.

In this lesson, you'll learn what interfaces are, why they exist, how they differ from abstract classes, and how to use them effectively in your .NET applications.

What Is It?

The Simple Explanation

An interface is like a contract. It says: "If you want to be a printable thing, you must have a Print() method." It doesn't say how that method works — that's up to the class that signs the contract.

The Technical Definition

In C#, an interface is a reference type that defines a set of abstract members — methods, properties, events, or indexers — that a class or struct must implement. Interfaces contain no implementation (except for default interface methods introduced in C# 8.0, but we'll focus on the classic case).

• Members are implicitly public and abstract — you don't use access modifiers.
• A class can implement multiple interfaces — this is C#'s way of achieving multiple inheritance of behavior.
• Interfaces can inherit from other interfaces, creating a hierarchy of contracts.
• Structs can also implement interfaces, not just classes.

Why Does It Exist?

The Problem

Without interfaces, you'd have to write code that knows about every concrete type. For example, a Printer class would need to check: "Is this a Document? Then call Document.Print(). Is it an Image? Then call Image.Print()." Every time you add a new printable type, you'd have to modify the Printer class. This is tight coupling and violates the Open/Closed principle.

The Solution

Interfaces invert the dependency. The Printer class depends on the IPrintable interface, not on concrete types. New printable classes can be added without changing Printer — as long as they implement the interface. This is dependency inversion and enables polymorphism without inheritance.

Big Picture

How It Works

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

public class Document : IPrintable
{
    public string Title { get; set; }
    public void Print() => Console.WriteLine($"Printing: {Title}");
}

void PrintAll(IPrintable[] items)
{
    foreach (var item in items)
        item.Print();
}

Simple Example

// ─── Define the interface ───
public interface IAnimal
{
    string Speak();
}

// ─── Implement the interface ───
public class Dog : IAnimal
{
    public string Speak() => "Woof!";
}

public class Cat : IAnimal
{
    public string Speak() => "Meow!";
}

public class Duck : IAnimal
{
    public string Speak() => "Quack!";
}

// ─── Use the interface ───
public class AnimalSoundMaker
{
    public void MakeSound(IAnimal animal)
    {
        Console.WriteLine(animal.Speak());
    }
}

// ─── Usage ───
var maker = new AnimalSoundMaker();
maker.MakeSound(new Dog());   // "Woof!"
maker.MakeSound(new Cat());   // "Meow!"
maker.MakeSound(new Duck());  // "Quack!"

Code → Meaning → Result

• The IAnimal interface defines a contract: any animal must be able to Speak().
• Each class provides its own implementation of Speak().
• AnimalSoundMaker works with the interface, not concrete types. It doesn't care if it's a dog, cat, or duck — it just calls Speak().
• This is polymorphism via interfaces — a powerful alternative to inheritance-based polymorphism.

Real-World Example

Consider an e-commerce system with multiple payment gateways. You want to support Stripe, PayPal, and a bank transfer, but your order processing logic should be agnostic.

// ─── Interface ───
public interface IPaymentProcessor
{
    bool ProcessPayment(decimal amount, string currency);
}

// ─── Implementations ───
public class StripeProcessor : IPaymentProcessor
{
    public bool ProcessPayment(decimal amount, string currency)
    {
        Console.WriteLine($"Stripe: processing {amount} {currency}");
        // Stripe API call...
        return true;
    }
}

public class PayPalProcessor : IPaymentProcessor
{
    public bool ProcessPayment(decimal amount, string currency)
    {
        Console.WriteLine($"PayPal: processing {amount} {currency}");
        // PayPal API call...
        return true;
    }
}

public class BankTransferProcessor : IPaymentProcessor
{
    public bool ProcessPayment(decimal amount, string currency)
    {
        Console.WriteLine($"Bank transfer: processing {amount} {currency}");
        // Bank transfer logic...
        return true;
    }
}

// ─── Order Service ───
public class OrderService
{
    private readonly IPaymentProcessor _paymentProcessor;

    public OrderService(IPaymentProcessor paymentProcessor)
    {
        _paymentProcessor = paymentProcessor;
    }

    public void Checkout(decimal amount, string currency)
    {
        if (_paymentProcessor.ProcessPayment(amount, currency))
            Console.WriteLine("Order completed!");
        else
            Console.WriteLine("Payment failed.");
    }
}

// ─── Usage ───
var orderService = new OrderService(new StripeProcessor());
orderService.Checkout(99.99m, "USD");

orderService = new OrderService(new PayPalProcessor());
orderService.Checkout(49.50m, "EUR");

What's happening here?

• Interface — IPaymentProcessor defines the contract for all payment gateways.
• Implementations — each gateway provides its own logic, but all obey the same interface.
• Dependency Injection — OrderService receives the processor via its constructor. It depends on the abstraction (interface), not the concretion.
• Flexibility — you can switch payment processors without changing OrderService. This makes the system pluggable and testable (you can mock the interface in unit tests).

Analogy

Under the Hood

Common Confusion

1. Interface vs Abstract Class

This is the most common point of confusion. Both define contracts, but they serve different purposes.

2. Interfaces vs Base Classes — Which to choose?

Use an interface when:

• You want to define a contract that can be implemented by unrelated classes
• You need multiple inheritance of behavior
• You're building a plug-in architecture

Use an abstract class when:

• You want to share code among closely related classes
• You need to define common fields or state
• You want to provide a default implementation that can be overridden

Common Mistakes

Mistake 1 — Forgetting to implement all interface members

If you implement an interface but forget a method, you get a compiler error.

public interface IWorker
{
    void Work();
    void Rest();
}
public class Employee : IWorker
{
    public void Work() => Console.WriteLine("Working...");
    //  Missing Rest() → compiler error
}

Mistake 2 — Using public keyword in an interface

Interface members are implicitly public. Adding public is redundant and causes a warning.

public interface IExample
{
    public void DoWork();  //  "public" is not needed
}

Mistake 3 — Not using interfaces for dependency injection

When you create tightly coupled code, you lose testability and flexibility.

public class OrderService
{
    private StripeProcessor _processor = new StripeProcessor();  //  concrete dependency
    // Hard to test, hard to swap.
}

Instead, depend on the interface and inject it.

Mistake 4 — Changing an interface after it's published

Adding a new method to an existing interface breaks all implementing classes. This is a binary breaking change. If you need to add functionality, consider a new interface or use default interface methods (C# 8+).

When Should I Use It?

Use an interface when:

• You want to define a contract that multiple classes can fulfill, especially unrelated ones
• You need multiple inheritance of behavior (a class can implement many interfaces)
• You're building a pluggable architecture (e.g., plugins, payment gateways, logging providers)
• You want to enable dependency injection and unit testing by mocking dependencies
• You're designing a library or framework and want to decouple your API from implementation details

When you might not need an interface:

• If you have only one implementation and it's unlikely to change, an interface may be overkill (but still good practice for testability)
• If you need to share implementation code, an abstract class is more appropriate
• If the contract is very small and you're writing a quick script, you might skip it

Mental Model

Key Takeaway

Check Your Understanding

You've seen how interfaces define contracts, enable polymorphism, and decouple your code. Let's see if you can apply this knowledge.

public interface IHasName
{
    string Name { get; set; }
}
public class Person : IHasName
{
    public string Name { get; set; }
}
public class Animal : IHasName
{
    // Notice: no Name property
}

You now have a solid foundation in interfaces — you can define them, implement them, and use them to build flexible, decoupled systems!