The "I" in SOLID. No class should be forced to depend on methods it doesn't use.

Somewhere in a lot of real codebases, there's an interface that looks like this — grown one "just add it here" decision at a time over a couple of years:

public interface IRepository<T>
{
    Task<T?> GetByIdAsync(Guid id);
    Task<IReadOnlyList<T>> GetAllAsync();
    Task AddAsync(T entity);
    Task UpdateAsync(T entity);
    Task DeleteAsync(Guid id);
    Task<IReadOnlyList<T>> SearchAsync(string query);
    Task BulkImportAsync(IEnumerable<T> entities);
    Task<int> CountAsync();
    Task ArchiveAsync(Guid id);
    Task RestoreFromArchiveAsync(Guid id);
}

// A read-only reporting screen just wants to list customers...
public sealed class CustomerListViewModel(IRepository<Customer> repository)
{
    public Task<IReadOnlyList<Customer>> LoadAsync() => repository.GetAllAsync();
    // ...but it's now coupled to Add, Update, Delete, BulkImport, Archive, Restore —
    // ten members, when it only ever calls one.
}

Nothing here fails to compile. But every single consumer of IRepository<T> — including a read-only reporting screen that will never call DeleteAsync in its life — is coupled to all ten members. A test fake for CustomerListViewModel has to implement all ten, even though nine of them are irrelevant noise. This is what a "fat" interface costs you, quietly, everywhere it's used.

In this lesson, you'll learn the Interface Segregation Principle — the "I" in SOLID — why fat interfaces hurt in ways that aren't obvious until you try to test or extend them, how to split a bloated interface into focused ones, and how to do it on a real IRepository example.

What Is the Interface Segregation Principle?

The Interface Segregation Principle (ISP) states: no client should be forced to depend on methods it does not use. In practice, this means preferring several small, focused interfaces over one large interface that tries to cover every possible need of every possible consumer.

You already saw ISP in action, informally, in lesson 078 — INotificationChannel, IConfigurable, and IStartupHealthCheckable were kept separate specifically so a plugin only had to implement the capabilities it genuinely had. ISP is the name for that instinct, generalized into a rule you can apply deliberately.

Why Fat Interfaces Hurt

An interface with too many members creates a specific chain of real costs, not just an aesthetic complaint:

• Unnecessary coupling. Every consumer of IRepository<T> is coupled to all ten members, whether it uses one or all ten — a change to BulkImportAsync's signature can force a recompile of code that never calls it.
• Painful test doubles. A fake implementation for a read-only view model still has to stub out AddAsync, DeleteAsync, ArchiveAsync, and every other member — usually with throw new NotSupportedException(), which is a Liskov Substitution violation waiting to happen (lesson 074).
• Hidden, misleading permissions. A method that only needs to read data, but receives the full IRepository<T>, looks — to anyone reading the code — like it might also delete or archive records. The signature lies about what the method actually does.
• Implementations that can't honestly satisfy the whole contract. An append-only audit log store might have no sensible way to implement DeleteAsync at all — forcing it to throw, fake it, or violate its own domain rules just to satisfy a compiler requirement it shouldn't have had in the first place.

Big Picture — Splitting a Bloated IRepository

Splitting a Bloated Interface — the Steps

Simple Example

//  Before — one fat interface
public interface IWorker
{
    void Work();
    void Eat();
    void Sleep();
}

// A robot worker can Work() just fine, but eating and sleeping make no sense for it.
public sealed class RobotWorker : IWorker
{
    public void Work() => Console.WriteLine("Welding...");
    public void Eat() => throw new NotSupportedException("Robots don't eat.");   //  LSP violation
    public void Sleep() => throw new NotSupportedException("Robots don't sleep.");
}

//  After — segregated by actual capability
public interface IWorkable { void Work(); }
public interface IFeedable { void Eat(); }
public interface IRestable { void Sleep(); }

public sealed class RobotWorker : IWorkable   // only implements what genuinely applies
{
    public void Work() => Console.WriteLine("Welding...");
}

public sealed class HumanWorker : IWorkable, IFeedable, IRestable
{
    public void Work() => Console.WriteLine("Writing code...");
    public void Eat() => Console.WriteLine("Lunch break.");
    public void Sleep() => Console.WriteLine("Going home.");
}

Code → Meaning → Result: RobotWorker no longer has to lie about capabilities it doesn't have. Any code that only needs "something that can work" depends on IWorkable alone, and both worker types satisfy it honestly — no throwing, no fake implementations.

Real-World Example — Segregating IRepository<T>, in Full

public interface IReadableRepository<T>
{
    Task<T?> GetByIdAsync(Guid id, CancellationToken ct = default);
    Task<IReadOnlyList<T>> GetAllAsync(CancellationToken ct = default);
    Task<int> CountAsync(CancellationToken ct = default);
}

public interface IWritableRepository<T>
{
    Task AddAsync(T entity, CancellationToken ct = default);
    Task UpdateAsync(T entity, CancellationToken ct = default);
    Task DeleteAsync(Guid id, CancellationToken ct = default);
}

public interface IArchivableRepository<T>
{
    Task ArchiveAsync(Guid id, CancellationToken ct = default);
    Task RestoreFromArchiveAsync(Guid id, CancellationToken ct = default);
}

// The full SQL-backed implementation genuinely supports everything
public sealed class SqlCustomerRepository(DbConnection connection)
    : IReadableRepository<Customer>, IWritableRepository<Customer>, IArchivableRepository<Customer>
{
    public Task<Customer?> GetByIdAsync(Guid id, CancellationToken ct = default) => /* ... */ default!;
    public Task<IReadOnlyList<Customer>> GetAllAsync(CancellationToken ct = default) => /* ... */ default!;
    public Task<int> CountAsync(CancellationToken ct = default) => /* ... */ default!;
    public Task AddAsync(Customer entity, CancellationToken ct = default) => /* ... */ Task.CompletedTask;
    public Task UpdateAsync(Customer entity, CancellationToken ct = default) => /* ... */ Task.CompletedTask;
    public Task DeleteAsync(Guid id, CancellationToken ct = default) => /* ... */ Task.CompletedTask;
    public Task ArchiveAsync(Guid id, CancellationToken ct = default) => /* ... */ Task.CompletedTask;
    public Task RestoreFromArchiveAsync(Guid id, CancellationToken ct = default) => /* ... */ Task.CompletedTask;
}

// A read-only reporting view model now depends on EXACTLY what it uses
public sealed class CustomerListViewModel(IReadableRepository<Customer> repository)
{
    public Task<IReadOnlyList<Customer>> LoadAsync(CancellationToken ct = default) =>
        repository.GetAllAsync(ct);
}

// An append-only audit log store implements ONLY what it can honestly support —
// no DeleteAsync to fake, no ArchiveAsync that makes no sense for an audit trail
public sealed class SqlAuditLogRepository(DbConnection connection)
    : IReadableRepository<AuditEntry>, IWritableRepository<AuditEntry>
{
    // Note: implements Add/Update but no need to implement IArchivableRepository at all —
    // there's simply no such interface reference for it to satisfy or fake.
    public Task<AuditEntry?> GetByIdAsync(Guid id, CancellationToken ct = default) => /* ... */ default!;
    public Task<IReadOnlyList<AuditEntry>> GetAllAsync(CancellationToken ct = default) => /* ... */ default!;
    public Task<int> CountAsync(CancellationToken ct = default) => /* ... */ default!;
    public Task AddAsync(AuditEntry entity, CancellationToken ct = default) => /* ... */ Task.CompletedTask;
    public Task UpdateAsync(AuditEntry entity, CancellationToken ct = default) =>
        throw new InvalidOperationException("Audit entries are immutable once written.");
    public Task DeleteAsync(Guid id, CancellationToken ct = default) =>
        throw new InvalidOperationException("Audit entries cannot be deleted.");
}

Why this segregation genuinely pays off:

• CustomerListViewModel's test fake now needs to implement three methods, not ten — a fake that used to be a wall of stubs is now three honest lines.
• SqlAuditLogRepository simply never has to implement ArchiveAsync or RestoreFromArchiveAsync — those methods don't exist for it to fake or throw from, because it never claimed to support that capability.
• A code reviewer looking at CustomerListViewModel's constructor immediately knows, from the type alone, that this class cannot delete or archive customer data — the dependency's shape documents the class's actual permissions.
• UpdateAsync and DeleteAsync still technically throw on the audit log — but only because those methods were explicitly needed for a narrower reason (the writable interface still fits, mostly); a stricter design might split IWritableRepository further into IInsertOnlyRepository for exactly this case, which is a legitimate next iteration of applying ISP again.

Under the Hood — Why This Costs Nothing at Runtime

Common Confusion

ISP vs. "just implement more interfaces on one class" (lesson 078)

Lesson 078 was about a class implementing several already-well-sized interfaces. ISP is the earlier, upstream design question: how big should each of those interfaces be in the first place? They work together — ISP tells you how to shape the individual interfaces; lesson 078's multiple-implementation pattern is how a class combines several of them once they're properly sized.

"Small interfaces" doesn't mean "one member per interface, always"

ISP is about grouping members by who genuinely needs them together, not about mechanically shrinking every interface to a single method. IReadableRepository<T> above has three members — that's fine, because GetByIdAsync, GetAllAsync, and CountAsync are genuinely used together by the same kind of read-only consumer. Splitting them further would add ceremony without reducing any real coupling.

Common Mistakes

Mistake 1 — Adding "just one more method" to an existing interface, repeatedly, without reconsidering its shape

This is exactly how IRepository<T> grew to ten members in the first place — each individual addition looked harmless, and nobody stopped to ask whether it belonged with the rest.

Before adding a member to an existing interface, ask who will consume it and whether it genuinely belongs with the interface's existing members, or deserves its own focused interface instead.

Mistake 2 — Over-segregating into a single-method interface for every conceivable member

Splitting IReadableRepository<T> into IGetByIdRepository<T>, IGetAllRepository<T>, and ICountRepository<T>, when every real consumer of "read" behavior always needs all three together anyway — this multiplies interface count without reducing any actual coupling.

Segregate along real usage boundaries, not arbitrarily. If two members are always needed together by every consumer, keeping them on the same interface is the right call, not a violation of ISP.

Mistake 3 — Depending on the fat interface out of habit, even after segregated ones exist

A newly-written, read-only reporting class that still takes IRepository<T> in its constructor "because that's what everyone uses," even though IReadableRepository<T> now exists and would be more honest.

Once focused interfaces exist, use the narrowest one that satisfies the class's actual needs — the benefit of segregation is only realized when consumers actually adopt the narrower contract.

When Should I Use It?

• An existing interface has grown past what any single consumer actually uses, and different consumers clearly use different, non-overlapping subsets of it.
• A concrete implementation has to throw or fake a member because it genuinely can't support it — a strong signal that member belongs in a separate, more specific interface.
• Writing a test fake for a class has become tedious because the interface it depends on has far more members than that class actually calls.

Mental Model

Key Takeaway

Check Your Understanding

Let's confirm you can recognize a fat interface and know how to fix it properly.

You can now spot a fat interface on sight and know exactly how to fix it — which sets up explicit interface implementation (080), the precision tool for when two focused interfaces genuinely collide.

dotnetmadeeasy.com — Learn C# and .NET, the right way.