DEV Community

Sathish
Sathish

Posted on • Originally published at sathishsaravanan.com

1

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();
}
Enter fullscreen mode Exit fullscreen mode

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)
    }
}
Enter fullscreen mode Exit fullscreen mode

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();
}
Enter fullscreen mode Exit fullscreen mode

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...");
}
Enter fullscreen mode Exit fullscreen mode

Cleaner, clearer, and no wasted methods.

📦 A More Realistic Use Case: Invoicing

Let’s bring it back to invoices. You might start with:

public interface IInvoiceHandler
{
    void Save();
    void Email();
    void Print();
}
Enter fullscreen mode Exit fullscreen mode

But what if some invoices are draft-only, or internal, and don’t need to be emailed or printed?

Split the interface:

public interface IInvoiceSaver
{
    void Save();
}

public interface IInvoiceMailer
{
    void Email();
}

public interface IInvoicePrinter
{
    void Print();
}
Enter fullscreen mode Exit fullscreen mode

Now your classes aren’t cluttered with unused methods or fake throw logic. Each one does exactly what it needs to—and nothing more.

🧪 A Quick Check

Ask yourself:

  • Is this class implementing methods it doesn’t actually use?
  • Are you seeing “not supported” or empty implementations?
  • Could this interface be broken into smaller, more focused pieces?

If yes, you’re likely looking at an ISP violation.

💬 Final Thoughts

The Interface Segregation Principle is all about respect. Respect for your classes, your future teammates, and your own sanity.

When interfaces are clean and focused, your code becomes easier to understand, test, and extend. No more placeholder methods. No more fake support for features. Just clean, intentional design.

So next time you're tempted to add “just one more method” to that interface, pause—and maybe make a new one instead.

A good interface is like a good conversation—short, relevant, and free of awkward silence.

AWS Security LIVE! Stream

Streaming live from AWS re:Inforce

Tune into Security LIVE! at re:Inforce for expert takes on modern security challenges.

Learn More

Top comments (0)

AWS GenAI LIVE image

How is generative AI increasing efficiency?

Join AWS GenAI LIVE! to find out how gen AI is reshaping productivity, streamlining processes, and driving innovation.

Learn more

AWS Security LIVE! From re:Inforce 2025

Tune into AWS Security LIVE! streaming live from the AWS re:Inforce expo floor in Philadelphia from 8:00AM ET-6:00PM ET.

Tune in to the full event

DEV is partnering to bring live events to the community. Join us or dismiss this billboard if you're not interested. ❤️