Interface Segregation Principle

Microsoft's Component Object Model (COM)COM was Microsoft's binary interface standard for component software (1993). Every COM object implemented IUnknown with QueryInterface(), which let clients ask "do you support IPrint?" before using print features. This is ISP enforced at the binary level. was practicing ISP before it had a name. Every COM object implemented IUnknown with its QueryInterface() method — clients asked "do you support this interface?" before using it. COM objects could expose dozens of interfaces, and each client queried only the ones it needed. The design was driven by practical necessity: COM components from different vendors, written in different languages, couldn't share a fat base class.

.NET 1.0 shipped with some famously fat interfaces. ICollection included IsSynchronized and SyncRoot — properties that almost no one used and that .NET Core eventually deprecated in spiritIn .NET Core, collections no longer implement meaningful IsSynchronized/SyncRoot behavior — they return false/throw. The properties exist only for binary compatibility. This is a legacy ISP violation that couldn't be removed without breaking existing code.. IList included both read and write operations, forcing read-only collections to throw NotSupportedException on Add() and Remove() — a textbook ISP violation that would take a decade to fix.

.NET 4.5 introduced IReadOnlyList<T>, IReadOnlyCollection<T>, and IReadOnlyDictionary<TKey, TValue> — the BCL team'sBase Class Library team — the Microsoft engineers who design and maintain .NET's core types (System.Collections, System.IO, System.Linq, etc.). Their interface design decisions affect every .NET developer. official response to a decade of ISP violations. Now read-only consumers could depend on IReadOnlyList<T> instead of IList<T>, eliminating the need for NotSupportedException on write methods. List<T> was updated to implement both IList<T> and IReadOnlyList<T>.

Modern .NET embraces ISP at every level. IHost vs IHostBuilder vs IHostedService — each with a focused responsibility. IOptions<T> vs IOptionsSnapshot<T> vs IOptionsMonitor<T> — three interfaces for three use casesIOptions<T> is singleton (read once). IOptionsSnapshot<T> is scoped (re-reads per request). IOptionsMonitor<T> is singleton but watches for changes. Three different interfaces because three different clients need different behaviors.. ASP.NET Core filters (IActionFilter, IAuthorizationFilter, IExceptionFilter, IResultFilter, IResourceFilter) — five separate filter interfaces instead of one IFilter with everything. The C# 8 default interface methods (DIMs)C# 8 (2019) let interfaces have method implementations. This helps ISP by letting you add new methods to an interface without breaking existing implementers — they get the default implementation. It's a migration tool, not a reason to make fat interfaces. (2019) feature also helps evolve interfaces without breaking implementers.

ASP.NET Core has five separate filter interfaces instead of one IFilter. Each runs at a different stage of the request pipeline:

// 5 filter interfaces — each serves a different stage of the pipeline
public interface IAuthorizationFilter
{
    void OnAuthorization(AuthorizationFilterContext context);
}
public interface IResourceFilter
{
    void OnResourceExecuting(ResourceExecutingContext context);
    void OnResourceExecuted(ResourceExecutedContext context);
}
public interface IActionFilter
{
    void OnActionExecuting(ActionExecutingContext context);
    void OnActionExecuted(ActionExecutedContext context);
}
public interface IExceptionFilter
{
    void OnException(ExceptionContext context);
}
public interface IResultFilter
{
    void OnResultExecuting(ResultExecutingContext context);
    void OnResultExecuted(ResultExecutedContext context);
}

// A logging filter only cares about action execution:
public class RequestLoggingFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
        => Log.Information("Executing {Action}", context.ActionDescriptor.DisplayName);

    public void OnActionExecuted(ActionExecutedContext context)
        => Log.Information("Executed {Action} in {Ms}ms", context.ActionDescriptor.DisplayName,
            context.HttpContext.Items["elapsed"]);
    // Doesn't implement IAuthorizationFilter, IExceptionFilter, etc.
}

// A caching filter only cares about resource-level:
public class ResponseCacheFilter : IResourceFilter
{
    public void OnResourceExecuting(ResourceExecutingContext context) => /* check cache */;
    public void OnResourceExecuted(ResourceExecutedContext context) => /* store in cache */;
}

The Options patternASP.NET Core's configuration binding system. Instead of reading raw IConfiguration everywhere, you bind configuration sections to strongly-typed classes. The three IOptions interfaces control how and when the configuration is read. uses three interfaces for three different configuration needs:

// Three interfaces for three different consumer needs:

// 1. IOptions<T> — read once at startup, never refreshes (singleton)
public class StartupValidator(IOptions<DatabaseOptions> dbOpts)
{
    public void Validate() => /* dbOpts.Value is always the startup value */;
}

// 2. IOptionsSnapshot<T> — re-reads per scope/request (scoped)
public class PerRequestHandler(IOptionsSnapshot<FeatureFlags> flags)
{
    public void Handle() => /* flags.Value refreshes per HTTP request */;
}

// 3. IOptionsMonitor<T> — watches for changes, notifies (singleton)
public class ConfigWatcher
{
    public ConfigWatcher(IOptionsMonitor<AppSettings> monitor)
    {
        monitor.OnChange(settings => Log.Information("Config changed!"));
    }
}

// ISP: each consumer declares exactly the behavior it needs.
// A singleton service should NEVER depend on IOptionsSnapshot (it's scoped).
// A per-request handler doesn't need OnChange callbacks.

MediatR splits messaging into two distinct interfaces:

// IRequest<T> — one sender, one handler, returns a response
public record GetOrderQuery(int Id) : IRequest<OrderDto>;

public class GetOrderHandler : IRequestHandler<GetOrderQuery, OrderDto>
{
    public async Task<OrderDto> Handle(GetOrderQuery request, CancellationToken ct)
        => /* fetch and return order */;
}

// INotification — one publisher, MANY handlers, no response
public record OrderPlacedEvent(int OrderId) : INotification;

public class SendEmailOnOrder : INotificationHandler<OrderPlacedEvent>
{
    public async Task Handle(OrderPlacedEvent notification, CancellationToken ct)
        => /* send confirmation email */;
}

public class UpdateInventoryOnOrder : INotificationHandler<OrderPlacedEvent>
{
    public async Task Handle(OrderPlacedEvent notification, CancellationToken ct)
        => /* decrement stock */;
}

// ISP: Handlers implement IRequestHandler OR INotificationHandler — never both.
// Each handler knows exactly one thing about the system.

The .NET hosting model splits the application lifecycle into focused interfaces:

// IHostBuilder — configures the app BEFORE it starts
// Only startup code uses this interface
public interface IHostBuilder  // Simplified — also has ConfigureHostConfiguration, Properties, etc.
{
    IHostBuilder ConfigureServices(Action<HostBuilderContext, IServiceCollection> configure);
    IHostBuilder ConfigureAppConfiguration(Action<HostBuilderContext, IConfigurationBuilder> configure);
    IHost Build();
    // Note: single-param overloads (Action<IServiceCollection>) are extension methods
}

// IHost — runs the app AFTER configuration
// Only the entry point uses this interface
public interface IHost : IDisposable
{
    IServiceProvider Services { get; }
    Task StartAsync(CancellationToken ct = default);
    Task StopAsync(CancellationToken ct = default);
}

// IHostedService — background work during app lifetime
// Only background workers implement this interface
public interface IHostedService
{
    Task StartAsync(CancellationToken ct);
    Task StopAsync(CancellationToken ct);
}

// Each phase of the lifecycle has its OWN interface.
// Background services don't see IHostBuilder.
// Startup config doesn't see IHostedService.
// Clean separation.

Before .NET Core 3.0, IDisposable was the only cleanup interface. But some resources (like database connections, HTTP streams) need async cleanupCalling Dispose() on an HTTP connection might need to send a close frame and wait for acknowledgment — that's async. With only IDisposable, you'd block the thread. IAsyncDisposable lets you await DisposeAsync() without blocking.. Instead of adding DisposeAsync() to IDisposable (which would force every IDisposable to implement it), .NET created a separate interface:

// Two separate interfaces — implement what you need
public interface IDisposable
{
    void Dispose();  // Sync cleanup
}

public interface IAsyncDisposable
{
    ValueTask DisposeAsync();  // Async cleanup
}

// Simple resource — sync only
public class FileHandle : IDisposable
{
    public void Dispose() => _handle.Close();
}

// Complex resource — both sync and async
public class DbConnection : IDisposable, IAsyncDisposable
{
    public void Dispose() => _connection.Close();
    public async ValueTask DisposeAsync() => await _connection.CloseAsync();
}

// Usage: await using for async, using for sync
await using var conn = new DbConnection();  // calls DisposeAsync()
using var file = new FileHandle();           // calls Dispose()

Imagine you hire a security guard and tell them: "Watch the front door, watch the cameras, and write down every visitor in the logbook." The guard watches the door and cameras just fine, but quietly ignores the logbook part — never writes a single entry. You would not know anything was wrong until someone asked "Who visited last Tuesday?" and the logbook was blank. That is what a no-op method does. It accepts the call, does absolutely nothing, and nobody finds out until it is too late.

The team built a single ILogger interface with five methods: three for general logging (info, warning, error), one for compliance audit trails, and one for performance metrics. The ConsoleLogger class implemented this interface. Console output is great for info/warning/error — you just print to the terminal. But audit logs need to go to a database (for compliance records), and metrics need to go to a monitoring system (like Prometheus or Datadog). The console cannot do either of those things.

The developer who wrote ConsoleLogger faced a choice: throw an exception (which would crash the app) or write an empty method body (which would keep things running). They chose the empty body. It seemed harmless. The code compiled, tests passed (nobody tested that audit events actually persisted), and the system ran smoothly for six months.

Then came the HIPAA compliance review. Auditors asked for records of who accessed patient data in the last quarter. The team went to the audit table — it was empty. Six months of patient access events, gone. Not corrupted, not encrypted, just never written. The ConsoleLogger had been silently swallowing every audit call. The team spent two weeks doing forensic reconstruction: cross-referencing application logs, database query logs, and access timestamps to rebuild what they could. Some events were unrecoverable. The resulting compliance gap led to a formal remediation plan and additional regulatory scrutiny.

Time to Diagnose

2 weeks of forensics to determine which audit events were lost and reconstruct them from other system logs. The no-op method compiled and ran without error — the bug was completely invisible.

// ❌ Fat logger interface — not every logger can handle every category
public interface ILogger
{
    void LogInfo(string message);
    void LogWarning(string message);
    void LogError(string message, Exception? ex = null);
    void LogAudit(string userId, string action, string resource);  // Compliance!
    void LogMetric(string name, double value);                     // Telemetry!
}

public class ConsoleLogger : ILogger
{
    public void LogInfo(string message) => Console.WriteLine($"[INFO] {message}");
    public void LogWarning(string message) => Console.WriteLine($"[WARN] {message}");
    public void LogError(string message, Exception? ex = null) => Console.Error.WriteLine($"[ERROR] {message}");

    // ❌ No-ops — console can't do audit or metrics, so... nothing
    public void LogAudit(string userId, string action, string resource) { }  // SILENT!
    public void LogMetric(string name, double value) { }                     // SILENT!
}

// ✅ Segregated — audit has its own interface that MUST be implemented properly
public interface IAppLogger
{
    void LogInfo(string message);
    void LogWarning(string message);
    void LogError(string message, Exception? ex = null);
}

public interface IAuditLogger
{
    void LogAudit(string userId, string action, string resource);
}

public interface IMetricsCollector
{
    void LogMetric(string name, double value);
}

public class ConsoleLogger : IAppLogger
{
    public void LogInfo(string message) => Console.WriteLine($"[INFO] {message}");
    public void LogWarning(string message) => Console.WriteLine($"[WARN] {message}");
    public void LogError(string message, Exception? ex) => Console.Error.WriteLine($"[ERROR] {message}");
    // No audit. No metrics. No silent no-ops.
}

public class SqlAuditLogger : IAuditLogger
{
    public void LogAudit(string userId, string action, string resource)
        => /* insert into audit_log table — guaranteed persistent */;
}

// Compliance code depends on IAuditLogger — console can NEVER be injected here
public class PatientRecordService(IAuditLogger audit)
{
    public void ViewRecord(string userId, string patientId)
    {
        audit.LogAudit(userId, "ViewRecord", patientId);  // ✅ Always reaches the DB
    }
}

Picture a shared Google Doc that 35 people have open. Every time anyone types a single character, everyone's copy refreshes and they lose their place. That is what happens with a fat interface referenced by many projects — any change to the interface forces every project that references it to recompile, even if the change is completely irrelevant to what that project does.

The team had a massive IUserService with 22 methods covering everything user-related: reading users, writing users, authentication, password management, profile updates, avatar uploads, role assignments, and email verification. This single interface lived in a shared "Contracts" assembly that 35 out of 80 projects referenced. It was the backbone of the entire system.

The problem was not a runtime crash — this is a developer productivity bug. When a developer on the authentication team added SendVerificationEmail(int userId) to the interface, the .NET compiler saw that the interface definition changed and recompiled every project that referenced it. The dashboard project (which only ever called GetById and GetPaged) had to recompile. The reporting project (which only called Search) had to recompile. The admin tool, the API gateway, the background workers — all 35 projects recompiled for a method none of them would ever call.

Each full rebuild took 12 minutes in CI. The team deployed three times per day, and nearly every deployment included at least one change to IUserService because it was the central hub for all user operations. Over time, developers started batching their changes to avoid triggering extra builds, which led to bigger, riskier pull requests. The feedback loop — "make a change, see if it works" — went from seconds (incremental compile) to minutes (full rebuild), and everyone felt the slowdown.

Time to Diagnose

Instant — the build log showed 35 projects recompiling. But the fix took 2 weeks: splitting IUserService into IUserReader, IUserWriter, IUserAuthenticator, and IUserProfileUpdater required updating 35 projects' dependency registrations.

// ❌ 22-method interface used by 35 projects
public interface IUserService
{
    User GetById(int id);
    User GetByEmail(string email);
    IEnumerable<User> Search(string query);
    PagedResult<User> GetPaged(int page, int size);
    void Create(User user);
    void Update(User user);
    void Delete(int id);
    void Activate(int id);
    void Deactivate(int id);
    bool Authenticate(string email, string password);
    void ChangePassword(int userId, string newPassword);
    void ResetPassword(string email);
    string GenerateToken(User user);
    bool ValidateToken(string token);
    void UpdateProfile(int userId, ProfileDto profile);
    void UploadAvatar(int userId, byte[] image);
    UserPreferences GetPreferences(int userId);
    void UpdatePreferences(int userId, UserPreferences prefs);
    void AssignRole(int userId, string role);
    void RemoveRole(int userId, string role);
    IEnumerable<string> GetRoles(int userId);
    void SendVerificationEmail(int userId);  // ← NEW: adding this recompiles everything
}

// The dashboard project only calls GetById + GetPaged + Search
// But it references IUserService, so ANY change triggers recompile

// ✅ Split by domain concern — each project references only what it needs
public interface IUserReader
{
    User GetById(int id);
    User GetByEmail(string email);
    IEnumerable<User> Search(string query);
    PagedResult<User> GetPaged(int page, int size);
}

public interface IUserWriter
{
    void Create(User user);
    void Update(User user);
    void Delete(int id);
    void Activate(int id);
    void Deactivate(int id);
}

public interface IUserAuthenticator
{
    bool Authenticate(string email, string password);
    void ChangePassword(int userId, string newPassword);
    void ResetPassword(string email);
    string GenerateToken(User user);
    bool ValidateToken(string token);
}

public interface IUserProfileUpdater
{
    void UpdateProfile(int userId, ProfileDto profile);
    void UploadAvatar(int userId, byte[] image);
    UserPreferences GetPreferences(int userId);
    void UpdatePreferences(int userId, UserPreferences prefs);
}

// Dashboard: only references IUserReader — auth changes don't recompile it
// Auth module: only references IUserAuthenticator
// Profile page: only references IUserProfileUpdater
// Adding SendVerificationEmail to IUserAuthenticator → only auth module recompiles

Imagine giving someone the keys to an entire building when they only need access to one room. Sure, you could just tell them "only go into Room 3," but keys do not come with instructions attached. Sooner or later, curiosity or a misunderstanding leads them into a room they were never supposed to enter. That is what happens when a read-only component receives a full CRUD interface — the "keys" to create, update, and delete are right there, tempting anyone who looks.

The dashboard was designed to display a list of users. It needed exactly one operation: "give me all users." But the developer who wired up the dependency injection registered IRepository<User>, a general-purpose repository with GetAll, GetById, Add, Update, and Delete. The dashboard only called GetAll(), so the extra methods seemed harmless — they were just sitting there, unused.

Then a junior developer was assigned to add some new features to the admin panel. They opened the DashboardController, looked at the injected IRepository<User>, and saw that Delete() was available. "Great," they thought, "the repository already supports deletion, so I can add a Delete User button." They wrote a [HttpDelete] endpoint that called repo.Delete(id). No authorization check — why would they add one? The interface itself implied that deletion was an expected operation. The code compiled, the code review focused on other aspects, and the feature shipped.

Within the first week, a support agent accidentally clicked "Delete" instead of "View" on the user table and removed 47 active user accounts. There was no confirmation dialog and no soft-delete — the repository's Delete() method was a hard delete. Recovery required a three-hour database restoration from backup, during which the entire system was in read-only mode. The post-mortem found the root cause: the dashboard should never have had access to write operations in the first place.

Time to Diagnose

Immediate — users called support. Recovery took 3 hours (database restore from backup). Root cause: the dashboard page had access to write operations it should never have seen.

// ❌ Dashboard gets full CRUD — only needs read
public class DashboardController(IRepository<User> repo) : ControllerBase
{
    [HttpGet] public IActionResult Index() => Ok(repo.GetAll());

    // Junior saw Delete() was available and added this:
    [HttpDelete("{id}")]
    public IActionResult Delete(int id)
    {
        repo.Delete(id);  // ❌ No authorization — the interface invited this!
        return Ok();
    }
}

// ✅ Dashboard gets read-only interface — Delete() doesn't exist
public class DashboardController(IReadRepository<User> repo) : ControllerBase
{
    [HttpGet] public IActionResult Index() => Ok(repo.GetAll());

    // Junior CAN'T add Delete — IReadRepository doesn't have it
    // The interface itself prevents the misuse
    // No amount of "be careful" comments can match compile-time safety
}

Think about filling out a government form where you need to answer 50 questions, but only 3 apply to your situation. You still have to look at all 50, decide which to skip, write "N/A" in the rest, and hope you did not accidentally skip one that mattered. After a few of these forms, you stop filling them out entirely. That is exactly what happened with unit tests here — the "form" (mock setup) was so long that developers stopped writing tests.

The team used MoqThe most popular mocking framework for .NET. Moq creates fake implementations of interfaces for testing. In Strict mode, it requires every method to be explicitly set up — calling an unset method throws an exception. In Loose mode, unset methods return default values, which can hide bugs. for unit testing. When you mock an interface in Moq's Strict mode (which is the safer option), you have to tell Moq what every single method should do. If any method gets called without a setup, the test fails with an unhelpful error. For an 18-method interface, that means 18 lines of setup code — even though the test only cares about 2 methods.

Developers responded in predictable ways. Some switched to MockBehavior.Loose, which silently returns null or zero for unconfigured methods — hiding real bugs. Some wrote shared "mock factory" methods that set up all 18 methods with defaults, but those factories became brittle and hard to maintain. Most developers simply stopped writing unit tests for anything order-related. "I will write an integration test later," they said. Later never came.

Over six months, test coverage on the order module dropped from 85% to 42%. Bugs that would have been caught by simple unit tests made it to production. The team blamed "test fatigue" and considered switching entirely to integration tests (which are slower and harder to debug). A senior engineer eventually traced the root cause back to the fat IOrderService interface: the pain was not in testing itself, but in the ceremony required to set up a mock for an interface with 18 methods when you only need 2.

Time to Diagnose

The team blamed "test fatigue" and considered switching to integration tests. A senior engineer finally identified the root cause: the fat interface made unit testing unreasonably expensive.

// ❌ 18-method interface — every test must mock all of them
[Fact]
public async Task CalculateTotal_AppliesDiscount()
{
    var mock = new Mock<IOrderService>();
    // Setup the 2 methods we actually need:
    mock.Setup(s => s.GetByIdAsync(1)).ReturnsAsync(testOrder);
    mock.Setup(s => s.GetDiscountAsync(1)).ReturnsAsync(0.1m);

    // But Moq's Strict mode requires ALL methods to be set up:
    mock.Setup(s => s.CreateAsync(It.IsAny<Order>())).ReturnsAsync(1);
    mock.Setup(s => s.UpdateAsync(It.IsAny<Order>())).Returns(Task.CompletedTask);
    mock.Setup(s => s.DeleteAsync(It.IsAny<int>())).Returns(Task.CompletedTask);
    mock.Setup(s => s.SearchAsync(It.IsAny<string>())).ReturnsAsync(Array.Empty<Order>());
    // ... 12 more lines of mock setup nobody reads
    // Developer gives up, uses MockBehavior.Loose, hides bugs
}

// ✅ Focused interface — only mock what you use
[Fact]
public async Task CalculateTotal_AppliesDiscount()
{
    var mock = new Mock<IOrderReader>();  // Only 4 methods exist
    mock.Setup(s => s.GetByIdAsync(1)).ReturnsAsync(testOrder);
    mock.Setup(s => s.GetDiscountAsync(1)).ReturnsAsync(0.1m);

    var calculator = new OrderCalculator(mock.Object);
    var total = await calculator.CalculateTotalAsync(1);

    Assert.Equal(90m, total);  // 100 * 0.9 discount
    // Clean. 2 setups for 2 calls. Zero noise.
}

Imagine a restaurant menu that lists "steak, chicken, fish, and custom orders." You go there every week and order a custom meal. One day the restaurant changes ownership, and the new owner decides they do not do custom orders anymore — but they leave the old menu up. You walk in, order your custom meal, and get told "sorry, we do not do that anymore." The menu (the interface) promised something the kitchen (the implementation) could no longer deliver.

In .NET, IList<T> is a deceptively broad interface. It promises not just reading (indexing, counting, enumerating) but also writing (Add, Remove, Insert). Both List<T> and arrays implement IList<T>. But arrays are fixed-size — you cannot add or remove elements. When you call Add() on an array through the IList<T> interface, it throws NotSupportedException at runtime.

The library originally returned new List<Product>(...) from its GetProducts() method. Consumers discovered they could call Add() on the result to append their own items — useful for customization. This worked because the underlying object was a real List<T> that supports Add(). The library's return type was IList<T>, which includes Add() in its contract, so consumers felt justified in using it.

Then version 1.1 came along. The library author added a caching layer and changed the return to _cache.ToArray() for performance. Arrays are faster for iteration but cannot be resized. The return type was still IList<T> — no structural breaking change. The library followed semantic versioningA versioning convention (MAJOR.MINOR.PATCH) where MINOR version bumps indicate backward-compatible new features. The library used a MINOR bump (v1.0 to v1.1), signaling no breaking changes. But the behavioral change (List to Array) was invisible to semver — the API surface looked the same while the runtime behavior broke. and considered this a non-breaking minor change. But hundreds of consumers that called Add() now got NotSupportedException at runtime. The API surface had not changed, but the behavior had — a subtle ISP violation where the return type promised more than the implementation could deliver.

Time to Diagnose

Immediate — consumers got NotSupportedException on upgrade. But the library had no breaking change in its API surface (still returned IList<T>). The break was behavioral, not structural.

// ❌ Library returns IList<T> — promises writable collection
public class DataService
{
    public IList<Product> GetProducts()
    {
        // v1.0: return new List<Product> { ... };  // Add() works
        // v1.1: return productsArray;                // Add() throws!
        return _cache.ToArray();  // Array implements IList but can't Add()
    }
}

// Consumer relied on Add() — breaks on upgrade
var products = service.GetProducts();
products.Add(customProduct);  // 💀 NotSupportedException in v1.1

// ✅ Return the NARROWEST interface that matches the actual capability
public class DataService
{
    // If consumers should only READ:
    public IReadOnlyList<Product> GetProducts()
        => _cache.ToArray();  // Array implements IReadOnlyList — no Add() exposed

    // If consumers genuinely need to modify:
    public List<Product> GetEditableProducts()
        => new List<Product>(_cache);  // Explicit: "you get a writable copy"
}

// Consumer sees exactly what they can do:
IReadOnlyList<Product> products = service.GetProducts();
// products.Add(x);  // Compile error — IReadOnlyList has no Add()
var editable = service.GetEditableProducts();
editable.Add(customProduct);  // ✅ Works — explicitly requested writable copy

Scan for NotImplementedException and NotSupportedException in production code — they're ISP violation indicatorsThink of these exceptions as "code smells with stack traces." NotImplementedException says "the developer couldn't implement this." NotSupportedException says "the type doesn't support this operation." Both mean the interface promises something the implementation can't deliver..

// Architecture test: no NotImplementedException in production code
[Fact]
public void ProductionCode_ShouldNotThrow_NotImplementedException()
{
    var types = Types.InAssembly(typeof(Program).Assembly);

    var result = types
        .That().DoNotHaveNameMatching(".*Tests?$")
        .ShouldNot()
        .HaveDependencyOn("System.NotImplementedException")
        .GetResult();

    Assert.True(result.IsSuccessful,
        $"Found NotImplementedException in: {string.Join(", ", result.FailingTypes?.Select(t => t.FullName) ?? Array.Empty<string>())}");
}

// Also check with Roslyn analyzer: IDE0051 (unused members) + CA1065 (throw in property)

Use MockBehavior.Strict in Moq to detect ISP violations. A strict mock throws on any method call you didn't explicitly set up — so if your class only needs 2 of 8 methods, you only set up those 2. If the test passes, great. If it blows up on an unexpected call, your interface is too fat for that consumer.

// Strict mocks throw on any unconfigured call — perfect ISP detector
[Fact]
public void UserLoader_OnlyNeedsGetById()
{
    // Only set up the methods your SUT actually needs
    var mock = new Mock<IFatRepository>(MockBehavior.Strict);
    mock.Setup(r => r.GetById(It.IsAny<int>())).Returns(new User());

    var sut = new UserLoader(mock.Object);
    sut.LoadUser(42);

    // If UserLoader secretly calls Delete() or Update() — BOOM!
    // Strict mock throws MockException on any unconfigured call.
    // That explosion is your ISP violation signal.
    mock.VerifyAll(); // Only configured methods were called
}

// If you only set up 2 of 8 methods and the test passes,
// your class doesn't need those other 6 methods.
// → Split the interface so this consumer gets a slim one.

Enforce ISP rules at the architecture level using NetArchTest — prevent fat interfaces from creeping back in.

using NetArchTest.Rules;

[Fact]
public void ReadOnlyServices_ShouldNotDependOn_WriteInterfaces()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().HaveNameEndingWith("ReadService")
        .Or().HaveNameEndingWith("QueryHandler")
        .ShouldNot()
        .HaveDependencyOn("IWriteRepository")
        .GetResult();

    Assert.True(result.IsSuccessful,
        "Read-only services must not depend on write interfaces");
}

[Fact]
public void Controllers_ShouldNotDependOn_FatInterfaces()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().HaveNameEndingWith("Controller")
        .ShouldNot()
        .HaveDependencyOnAny(
            "IUserService",      // Known fat interfaces
            "IOrderService",
            "IProductService")
        .GetResult();

    Assert.True(result.IsSuccessful,
        "Controllers should depend on segregated interfaces, not fat service interfaces");
}

The biggest performance impact of ISP is on build timeThe time it takes to compile your solution. In .NET, the compiler rebuilds any assembly whose dependencies changed. A fat interface in a shared project creates a dependency from every consuming project — so any change triggers a full solution rebuild. Segregated interfaces limit this to only affected projects., not runtime. In large solutions (50+ projects), changing a method on a fat interface triggers recompilation of every project that references it. Segregated interfaces limit the blast radius:

Registering multiple interfaces pointing to the same concrete type adds a few nanoseconds per resolution. The ASP.NET Core DI container uses dictionary lookupsMicrosoft.Extensions.DependencyInjection resolves services via hash table lookups on the service type. Adding more interface registrations adds more entries to the dictionary but doesn't change lookup time (O(1) hash lookup). The overhead is effectively zero for application-level code. — O(1) regardless of how many interfaces are registered. For singleton forwarding patterns, the factory delegate is resolved once and cached.

Migrating from a fat interface to segregated ones in a large codebase is scary. The Strangler Fig patternNamed after tropical fig trees that grow around a host tree, eventually replacing it entirely. In software, you build the new system alongside the old one, gradually routing traffic/consumers to the new system until the old one can be removed. Martin Fowler coined this term in 2004. (named after the tropical tree that grows around and eventually replaces its host) lets you migrate incrementally:

// STEP 1: Create segregated interfaces
public interface IUserReader { User GetById(int id); IEnumerable<User> Search(string q); }
public interface IUserWriter { void Create(User user); void Update(User user); void Delete(int id); }

// STEP 2: Make the fat interface extend them (backward compatible!)
public interface IUserService : IUserReader, IUserWriter
{
    // All existing methods are now "inherited" from sub-interfaces
    // Existing code that depends on IUserService STILL WORKS
}

// STEP 3: Migrate consumers one at a time
// Before: public class Dashboard(IUserService users)
// After:  public class Dashboard(IUserReader users)  // narrower dependency

// STEP 4: When no consumer depends on IUserService directly, delete it
// The "strangler fig" has fully replaced the host

// Bonus: Add a Roslyn analyzer or architecture test to BLOCK new IUserService dependencies
[Fact]
public void NewCode_ShouldNotDependOn_FatInterface()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .That().HaveNameEndingWith("Controller")
        .ShouldNot().HaveDependencyOn(typeof(IUserService).FullName)
        .GetResult();
    Assert.True(result.IsSuccessful);
}

Sometimes ISP leads to single-method interfaces. In C#, you have an alternative: delegates (or Func<T> / Action<T>). When should you use each?

// Option 1: Single-method interface
public interface IValidator<T> { bool Validate(T item); }
public class OrderValidator : IValidator<Order>
{
    public bool Validate(Order order) => order.Total > 0 && order.Items.Any();
}

// Option 2: Delegate / Func
public class OrderProcessor(Func<Order, bool> validate)
{
    public void Process(Order order)
    {
        if (!validate(order)) throw new ValidationException();
        // ...
    }
}

// WHEN TO USE EACH:
// Interface: when you need a NAME (IValidator), DI registration, or multiple implementations
// Delegate: when the behavior is a simple lambda, no DI needed, no name needed

// Interface wins: services.AddScoped<IValidator<Order>, OrderValidator>();
// Delegate wins: var processor = new OrderProcessor(o => o.Total > 0);

Create the segregated interfaces and make the fat interface extend them. This is backward-compatible — all existing code keeps working:

// NEW: segregated interfaces
public interface IUserReader { /* ... */ }
public interface IUserWriter { /* ... */ }
public interface IUserAuthenticator { /* ... */ }

// BRIDGE: fat interface extends all of them (backward compatible!)
[Obsolete("Use IUserReader/IUserWriter/IUserAuthenticator instead")]
public interface IUserService : IUserReader, IUserWriter, IUserAuthenticator { }

// The [Obsolete] attribute generates compiler warnings for existing consumers
// Guiding them to migrate without breaking their code

Update consumers one at a time, run tests after each change. Once no consumer depends on the fat interface, delete it:

// BEFORE (each PR changes one consumer):
public class DashboardController(IUserService users) // ⚠️ Obsolete warning

// AFTER:
public class DashboardController(IUserReader users)  // ✅ Clean

// When ALL consumers migrated:
// 1. Remove IUserService interface entirely
// 2. Update DI registration to use role interfaces
// 3. Add architecture test to prevent regression:
[Fact]
public void NoCode_ShouldDependOn_DeletedFatInterface()
{
    var result = Types.InAssembly(typeof(Program).Assembly)
        .ShouldNot().HaveDependencyOn("IUserService")
        .GetResult();
    Assert.True(result.IsSuccessful);
}