Interface Segregation Principle in C#: Build Interfaces People Actually Want to Use

Don’t Make Me Implement That We’ve all seen it—a class that’s forced to implement methods it doesn’t care about just because “the interface says so.” That’s what the Interface Segregation Principle (ISP) is here to fix. Clients should not be forced to depend on interfaces they do not use. — Robert C. Martin Let’s break that down with real-world C# examples and some common sense. The Problem: One Interface to Rule Them All Imagine we’re building a system for handling different types of documents. Here’s a common interface you might start with: public interface IDocumentProcessor { void Print(); void Fax(); void Scan(); } Looks fine, until we create a class for a DigitalDocument: public class DigitalDocument : IDocumentProcessor { public void Print() { throw new NotSupportedException("Cannot print digital-only documents."); } public void Fax() { throw new NotSupportedException("Fax not supported."); } public void Scan() { // Scan logic (maybe) } } We’re already violating the Interface Segregation Principle. The Smell: When throw Shows Up When your implementation starts throwing NotSupportedException, it’s a clear sign the interface is doing too much. The class is forced to depend on behaviors it doesn’t need, just to satisfy the compiler. And now, other parts of the system have to be defensive and check what’s really supported. ✅ The Fix: Split the Interface Let’s break things down into focused, role-specific interfaces: public interface IPrintable { void Print(); } public interface IFaxable { void Fax(); } public interface IScannable { void Scan(); } Now each class only implements what it actually supports: public class DigitalDocument : IScannable { public void Scan() { Console.WriteLine("Scanning digital document..."); } } public class PhysicalDocument : IPrintable, IFaxable, IScannable { public void Print() => Console.WriteLine("Printing..."); public void Fax() => Console.WriteLine("Faxing..."); public void Scan() => Console.WriteLine("Scanning..."); } Cleaner, clearer, and no wasted methods.

Mar 26, 2025 - 03:38

Interface Segregation Principle in C#: Build Interfaces People Actually Want to Use

Don’t Make Me Implement That

We’ve all seen it—a class that’s forced to implement methods it doesn’t care about just because “the interface says so.”

That’s what the Interface Segregation Principle (ISP) is here to fix.

Clients should not be forced to depend on interfaces they do not use. — Robert C. Martin

Let’s break that down with real-world C# examples and some common sense.

The Problem: One Interface to Rule Them All

Imagine we’re building a system for handling different types of documents. Here’s a common interface you might start with:

public interface IDocumentProcessor
{
    void Print();
    void Fax();
    void Scan();
}

Looks fine, until we create a class for a DigitalDocument:

public class DigitalDocument : IDocumentProcessor
{
    public void Print()
    {
        throw new NotSupportedException("Cannot print digital-only documents.");
    }

    public void Fax()
    {
        throw new NotSupportedException("Fax not supported.");
    }

    public void Scan()
    {
        // Scan logic (maybe)
    }
}

We’re already violating the Interface Segregation Principle.

The Smell: When `throw` Shows Up

When your implementation starts throwing NotSupportedException, it’s a clear sign the interface is doing too much.

The class is forced to depend on behaviors it doesn’t need, just to satisfy the compiler. And now, other parts of the system have to be defensive and check what’s really supported.

✅ The Fix: Split the Interface

Let’s break things down into focused, role-specific interfaces:

public interface IPrintable
{
    void Print();
}

public interface IFaxable
{
    void Fax();
}

public interface IScannable
{
    void Scan();
}

Now each class only implements what it actually supports:

public class DigitalDocument : IScannable
{
    public void Scan()
    {
        Console.WriteLine("Scanning digital document...");
    }
}

public class PhysicalDocument : IPrintable, IFaxable, IScannable
{
    public void Print() => Console.WriteLine("Printing...");
    public void Fax() => Console.WriteLine("Faxing...");
    public void Scan() => Console.WriteLine("Scanning...");
}

Cleaner, clearer, and no wasted methods.