Liskov Substitution Principle

Why This Happens: Inheritance is tempting when you see a class that already has the methods you need. "Why rewrite it? I'll just extend it and get everything for free." That reasoning feels efficient, but it conflates code reuse with behavioral compatibility. Inheritance says "my class IS a kind of that class." If that's not genuinely true in terms of behavior, you'll inherit methods that don't make sense for your type.

The classic example: making a Stack inherit from List<T>. You get Push and Pop for free (sort of), but you also inherit Insert(), RemoveAt(), and Add(). Those operations let someone stick items in the middle of the stack or remove from arbitrary positions. That completely breaks the LIFO contractLast-In-First-Out: a stack only allows Push (add to top) and Pop (remove from top). Inheriting from List exposes Insert-at-index and Remove-at-index, which break the LIFO invariant. Java's Stack class actually makes this mistake — it extends Vector.. A user who treats your Stack as a List will use it in ways your Stack never intended.

Java made this exact mistake: java.util.Stack extends Vector. Any code that holds a Vector reference to a Stack can call insertElementAt() and break the LIFO ordering. This has been a well-known design flaw since the 1990s.

// ❌ BAD: Stack inherits from List — exposes operations that break LIFO
public class MyStack<T> : List<T>
{
    public void Push(T item) => Add(item);
    public T Pop() { var item = this[^1]; RemoveAt(Count - 1); return item; }
}

var stack = new MyStack<int>();
stack.Push(1); stack.Push(2); stack.Push(3);
stack.Insert(0, 99);  // ← Inherited from List — breaks LIFO!
// Stack now has [99, 1, 2, 3] — not a valid stack state

// ✅ GOOD: Stack uses composition — only exposes Push and Pop
public class MyStack<T>
{
    private readonly List<T> _items = new();

    public void Push(T item) => _items.Add(item);
    public T Pop()
    {
        var item = _items[^1];
        _items.RemoveAt(_items.Count - 1);
        return item;
    }
    public int Count => _items.Count;
    // No Insert, no RemoveAt, no Add — LIFO is enforced
}

The difference is simple: with inheritance, you can't un-expose methods the parent class has. With composition, you control exactly which operations exist. The List is a private implementation detail that nobody outside the Stack can touch.

Why This Happens: You're building a class that needs to implement an interface, but one or two methods don't apply to your situation. The deadline is approaching, so you stub them out with throw new NotImplementedException() or throw new NotSupportedException(). Visual Studio even generates this as the default implementation when you auto-implement an interface. It feels safe because the code compiles, the other methods work, and "nobody calls that method anyway."

But here's the trap: the interface is a promise. When code accepts an IFileStorage, it trusts that every method works. If Delete() throws NotImplementedException, any code path that calls Delete() will crash at runtime. The compiler can't catch this because the method signature is satisfied; only the behavior is broken. This is LSP at its core: the subtype doesn't honor the contract the interface promises.

// ❌ BAD: Implementing an interface but refusing to honor part of the contract
public class ReadOnlyStorage : IFileStorage
{
    public byte[] Read(string path) => File.ReadAllBytes(path);  // ✅ works
    public void Write(string path, byte[] data) =>
        throw new NotSupportedException("Read-only!");           // ❌ bomb
    public void Delete(string path) =>
        throw new NotSupportedException("Read-only!");           // ❌ bomb
}

// ✅ GOOD: Split the interface so each class only promises what it can deliver
public interface IFileReader { byte[] Read(string path); }
public interface IFileWriter { void Write(string path, byte[] data); }
public interface IFileDeletor { void Delete(string path); }

public class ReadOnlyStorage : IFileReader
{
    public byte[] Read(string path) => File.ReadAllBytes(path);  // ✅ only promises Read
}

public class FullStorage : IFileReader, IFileWriter, IFileDeletor
{
    // Implements all three — every method works as expected
}

By splitting the interface (this is the Interface Segregation Principle working hand-in-hand with LSP), each class only implements the methods it can actually honor. No more dead methods that explode at runtime.

Why This Happens: You receive an interface reference, but one particular implementation needs special handling. Maybe circles need to be drawn differently, or premium customers need an extra step. So you write if (shape is Circle) to check the actual type at runtime. It feels like a quick, practical fix.

But every is or as check is a red flag. It means the interface abstraction has leaked. If the caller needs to know the concrete type, then the types aren't truly interchangeable. Every time a new subtype is added, someone has to update every if-else chain that checks types. This defeats the entire purpose of using interfaces and polymorphism in the first place.

Think of it like a restaurant. The waiter shouldn't need to know which brand of oven the kitchen uses. They just say "make this order" and trust the kitchen to figure it out. If the waiter starts checking "is this a gas oven? Then I need to adjust the temperature myself" that's a sign the kitchen isn't doing its job.

// ❌ BAD: Caller knows too much about the concrete type
public void Render(IShape shape)
{
    if (shape is Circle c)
        DrawCircle(c.Radius);       // Special path for Circle
    else if (shape is Rectangle r)
        DrawRect(r.Width, r.Height); // Special path for Rectangle
    // Every new shape = another "else if" here
}

// ✅ GOOD: Each shape knows how to render itself
public interface IShape { void Render(ICanvas canvas); }

public class Circle : IShape
{
    public double Radius { get; }
    public void Render(ICanvas canvas) => canvas.DrawCircle(Radius);
}

public class Rectangle : IShape
{
    public double Width { get; }
    public double Height { get; }
    public void Render(ICanvas canvas) => canvas.DrawRect(Width, Height);
}

// Caller code — no type checking needed
public void Render(IShape shape) => shape.Render(_canvas);

In the fixed version, the caller doesn't care what kind of shape it has. It just calls shape.Render() and the right behavior happens automatically. Adding a new shape (like Triangle) requires zero changes to the caller code.

Why This Happens: In the real world, a square IS a rectangle (it's a rectangle with equal sides). So it feels natural to make Square extend Rectangle in code. The domain model matches the real world. What could go wrong?

The problem is that real-world categories are about what things are, but programming hierarchies are about how things behave. A Rectangle with mutable dimensions lets you set width and height independently. A Square can't allow that because both dimensions must always be equal. If Square overrides the width setter to also change the height, then code that says rect.Width = 5; rect.Height = 10; assert(rect.Area == 50) fails when rect is actually a Square (area becomes 100 instead of 50).

// ❌ BAD: Domain truth ("square is a rectangle") doesn't hold in code
public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }
    public int Area => Width * Height;
}

public class Square : Rectangle
{
    public override int Width
    {
        set { base.Width = value; base.Height = value; } // Forces equality
    }
    public override int Height
    {
        set { base.Width = value; base.Height = value; } // Forces equality
    }
}

Rectangle rect = new Square();
rect.Width = 5;
rect.Height = 10;
// Expecting Area = 50, but it's 100 — Height setter overwrote Width!

// ✅ GOOD: Separate types behind a shared interface
public interface IShape { int Area { get; } }

public record Rectangle(int Width, int Height) : IShape
{
    public int Area => Width * Height;
}

public record Square(int Side) : IShape
{
    public int Area => Side * Side;
}
// No inheritance. No shared setters. No surprises.

The fix uses a shared IShape interface and immutable records. Rectangle and Square are separate, independent types. Neither one can break the other's behavior because they don't share any mutable state.

Why This Happens: An interface says GetByIdAsync returns an Order. The original SQL implementation always returns a valid order (throws if not found). Then someone writes a new implementation where sometimes the method silently returns null. Or a Save() method that does nothing because it's a test stub that accidentally leaked into production.

The developer thinks "I'm handling the edge case gracefully by returning null instead of throwing." But the caller was written to trust the original contract. It doesn't check for null. It chains method calls like order.Items.Count and gets a NullReferenceException three layers up the call stack, far from where the real problem is.

// ❌ BAD: Silently returns null when base contract promised non-null
public class CachedRepo : IOrderRepository
{
    public async Task<Order> GetByIdAsync(int id)
    {
        if (_cache.TryGetValue(id, out var order))
            return order;
        return null!;  // ← "null-forgiving" hides the violation from the compiler
    }
}
// Caller: var total = (await repo.GetByIdAsync(42)).Items.Sum(i => i.Price);
// NullReferenceException if 42 isn't in cache!

// ✅ GOOD: Make nullability explicit in the return type
public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(int id);  // ← "?" = might be null
}

// Now every caller MUST handle the null case
var order = await repo.GetByIdAsync(42);
if (order is null) { /* handle missing order */ }
var total = order.Items.Sum(i => i.Price);  // Compiler warns if null not handled

The fix is to make the postcondition honest. If some implementations might return null, make that part of the contract (Order? instead of Order). C# nullable reference typesC# 8+'s nullable reference types let you express "this returns null" (Task<Order?>) vs "this never returns null" (Task<Order>) at the type level. The compiler warns when a non-nullable return type might return null, catching potential NullReferenceExceptions at compile time. turn this from a runtime surprise into a compile-time warning.

Why This Happens: A developer overrides Equals() to compare by business key (email, SKU, etc.) but forgets to override GetHashCode() to match. Or they override both but base them on different fields. It's an easy mistake because the compiler only gives a warning (not an error), and the code seems to work in simple tests.

The Object class in .NET has a fundamental contract: if two objects are Equal, they must produce the same hash code. Hash-based collections (Dictionary, HashSet, LINQ's Distinct()) rely on this rule to work. They use the hash code to pick a bucket, then use Equals to compare within that bucket. If two "equal" objects land in different buckets, the collection will never realize they're the same.

// ❌ BAD: Equals uses Email, GetHashCode uses Id
public override bool Equals(object? obj) =>
    obj is User u && Email == u.Email;
public override int GetHashCode() => Id.GetHashCode(); // WRONG field!

// ✅ GOOD: Both methods use the same field(s)
public override bool Equals(object? obj) =>
    obj is User u && Email.Equals(u.Email, StringComparison.OrdinalIgnoreCase);
public override int GetHashCode() =>
    Email.GetHashCode(StringComparison.OrdinalIgnoreCase);

// ✅ BEST: Use a record — correct equality is automatic
public record User(int Id, string Email);

The safest approach: use C# record types. They auto-generate matching Equals and GetHashCode from all properties, making it impossible to get this wrong.

Why This Happens: A decorator or subtype seems like the perfect place to add caching, retry counts, or other stateful behavior. "I'll just wrap the original and cache the results for performance." But if the base type's contract implies that each method call is independent and stateless, introducing hidden state changes the observable behavior.

For example, a CachingDecorator around a stateless IProductService means the same call now returns different results depending on whether the cache is warm or cold. If another part of the system updates a product in the database, the cache still returns stale data. The original implementation always returned fresh data. That's a behavioral change the caller didn't ask for and doesn't know about.

// ❌ BAD: Introduces hidden state the base didn't have
public class CachingProductService : IProductService
{
    private readonly Dictionary<int, Product> _cache = new();  // hidden state!
    private readonly IProductService _inner;

    public Product GetById(int id) =>
        _cache.TryGetValue(id, out var p) ? p : (_cache[id] = _inner.GetById(id));
    // First call: fresh. Second call: stale. Third call after DB update: still stale!
}

// ✅ GOOD: Make caching explicit in the interface
public interface ICachedProductService : IProductService
{
    void InvalidateCache(int id);
    void InvalidateAll();
}
// Now callers KNOW this service caches. They can invalidate when needed.
// Or use a separate IDistributedCache as a cross-cutting concern.

If you need caching, either make it explicit in the interface (so callers know about it and can manage it) or use a dedicated caching layer separate from the business logic interface.

Why This Happens: You want to change what a method does in a derived class, but the base class didn't mark it as virtual. C# lets you "hide" the base method with the new keyword. It compiles without errors. But it creates a trap: the method called depends on the reference type (how you hold the variable), not the object type (what the object actually is).

This means the exact same object can behave differently depending on whether you hold it as a Base reference or a Derived reference. That directly contradicts substitutability: the whole point of LSP is that the reference type shouldn't matter.

// ❌ BAD: "new" hides the base method — behavior depends on reference type
public class Base { public virtual string Name() => "Base"; }
public class Derived : Base { public new string Name() => "Derived"; }

var d = new Derived();
Console.WriteLine(d.Name());           // "Derived"
Console.WriteLine(((Base)d).Name());   // "Base" — DIFFERENT behavior!
// Same object, two different answers. That's not substitutable.

// ✅ GOOD: "override" uses the runtime type — consistent behavior
public class Base { public virtual string Name() => "Base"; }
public class Derived : Base { public override string Name() => "Derived"; }

var d = new Derived();
Console.WriteLine(d.Name());           // "Derived"
Console.WriteLine(((Base)d).Name());   // "Derived" — SAME behavior!
// Doesn't matter how you hold the reference — the object type wins.

Use override instead of new. If the base method isn't virtual and you can't change it, that's a signal you shouldn't be inheriting from that class. Consider composition instead.

Why This Happens: A base method accepts any input (e.g., Process(Order order) works for any order). A developer creates a subtype that adds a business rule: "we only handle orders above $50." The subtype throws an exception or silently skips small orders. The caller had no idea about this restriction because the base type didn't have it.

This is called "strengthening the precondition." The base says "give me anything," but the subtype says "give me only this specific subset." That breaks substitutability: code that worked with the base type (passing any order) breaks with the subtype (which rejects small orders). LSP's rule is clear: subtypes can accept MORE inputs than the base (weaker preconditions), but never FEWER (stronger preconditions).

// ❌ BAD: Subtype demands MORE than the base — strengthened precondition
public class PremiumProcessor : OrderProcessor
{
    public override void Process(Order order)
    {
        if (order.Total < 50m)
            throw new ArgumentException("Order too small");  // Base didn't have this!
        base.Process(order);
    }
}

// ✅ GOOD: Capability checking instead of surprise rejection
public interface IOrderProcessor
{
    bool CanProcess(Order order);  // Let caller ask first
    void Process(Order order);
}

public class PremiumProcessor : IOrderProcessor
{
    public bool CanProcess(Order order) => order.Total >= 50m;
    public void Process(Order order) { /* ... */ }
}

The fix adds a CanProcess() method so callers can check before calling. This is the same pattern .NET's Stream uses with CanRead/CanWrite/CanSeek: capabilities are explicit, not surprise rejections.

Why This Happens: LSP is often taught using class inheritance examples (Rectangle/Square, Bird/Penguin), so many developers think it only matters when you write class Dog : Animal. But in modern C#, you rarely use class inheritance for polymorphism. You use interfaces. And LSP applies just as strongly to interface implementations.

Every time you register services.AddScoped<IRepository, SqlRepository>() in your DI container, you're creating a subtype relationship. SqlRepository is being substituted for IRepository. If SqlRepository behaves differently than what IRepository consumers expect (slower, throws different exceptions, returns null when others don't), that's an LSP violation. The same applies to decorators, adapters, mocks, and any wrapper that claims to implement an interface.

// ❌ BAD: LSP violation through DI — not inheritance
services.AddScoped<IEmailSender, FakeEmailSender>();  // For "testing"

public class FakeEmailSender : IEmailSender
{
    public Task SendAsync(string to, string body) =>
        Task.CompletedTask;  // Silently drops emails!
    // If this leaks to production, no emails go out.
    // LSP violation: interface says "sends email", implementation doesn't.
}

// ✅ GOOD: Every DI registration honors the interface contract
services.AddScoped<IEmailSender, SmtpEmailSender>();    // Production
services.AddScoped<IEmailSender, SendGridSender>();     // Alternative

// Both actually send emails. Both honor the postcondition.
// For tests, use a real test framework mock that VERIFIES calls were made,
// not a silent no-op that hides bugs.

The takeaway: any time you swap one implementation for another (through DI, decorators, adapters, or test doubles), ask yourself: "Will every consumer still work correctly with this new implementation?" That question IS the Liskov Substitution Principle.

Think of a rental car service. You book a "sedan" and they give you a Toyota Camry. Next time, they give you a Honda Accord. Both are sedans, both drive the same way, and your trip works fine regardless of which specific car you get. That's LSP: any "sedan" should work wherever a "sedan" is expected.

In code terms: if your code works with a base type (like IRepository), it should continue to work correctly with ANY implementation of that type (SqlRepository, MongoRepository, InMemoryRepository). No surprises, no unexpected exceptions, no weaker guarantees. The formal definition from Barbara Liskov says: if S is a subtype of T, then objects of type T can be replaced with objects of type S without altering the correctness of the program. In everyday .NET, this means every class that implements an interface must fully honor what that interface promises.

The Square/Rectangle problem. In geometry class, every square IS a rectangle. So in code, it seems logical to make Square inherit from Rectangle. But here's the trap: a Rectangle lets you set width and height independently. If you set width to 5 and height to 10, you expect the area to be 50. A Square overrides the setters to keep both dimensions equal. So setting height to 10 also sets width to 10, and the area becomes 100 instead of 50.

Code that says rect.Width = 5; rect.Height = 10; assert(rect.Area == 50) works perfectly with a real Rectangle, but breaks with a Square pretending to be a Rectangle. The fix is simple: don't use inheritance here. Use a shared IShape interface with separate, independent Rectangle and Square types. Domain truth ("a square is a rectangle") doesn't always translate to code truth ("a Square can substitute for a Rectangle").

Think of them as a team. OCP (Open/Closed Principle) says "extend your system by adding new classes, not by modifying existing ones." LSP says "those new classes better behave correctly when they're swapped in." Without LSP, OCP is dangerous: you add a shiny new PremiumDiscountCalculator, plug it in through dependency injection, and everything breaks because it returns negative values the caller didn't expect.

LSP is the enforcement mechanism that makes OCP safe. OCP opens the door to new implementations; LSP ensures every new implementation that walks through that door plays by the same rules. Together, they let you extend a system confidently: new classes can be added, and you can trust they won't break existing code.

Imagine a restaurant. The precondition is what you need before ordering: you must be seated and have a menu. A subtype (like a fast-food counter) can WEAKEN this: no seating required, just walk up. But it can't STRENGTHEN it: "you also need a reservation and a dress code" would break customers who were fine at regular restaurants.

The postcondition is what you're guaranteed after ordering: you get food that matches your order. A subtype can STRENGTHEN this: "you also get a free dessert." But it can't WEAKEN it: "we might give you someone else's order" violates the promise. The invariant is what's always true: "the kitchen is clean." It must hold before, during, and after your meal, in every restaurant type.

In code: preconditions are input requirements (argument not null), postconditions are output guarantees (return value >= 0), and invariants are properties that always hold (account balance never negative). Subtypes must not demand MORE input, must not guarantee LESS output, and must preserve all invariants.

The most famous one lives right in .NET's core library: System.IO.Stream. The base class defines Read(), Write(), and Seek(). But NetworkStream throws NotSupportedException if you call Seek(), because you can't jump to an arbitrary position in a network stream the way you can in a file.

The .NET team acknowledged this LSP violation and added capability flags as a workaround: CanRead, CanWrite, CanSeek. Before calling Seek(), you check stream.CanSeek. It's a pragmatic compromise: rather than splitting Stream into 7 separate interfaces (which would make the API unusable), they document the violation and give callers a way to check capabilities. Not perfect, but practical.

Three main strategies, and you'll use different ones depending on the situation:

1. Extract interface (split the contract). If an implementation can only do part of what the interface promises, the interface is too broad. Split it into smaller, focused interfaces. A Robot that can't Eat() doesn't implement IFeedable; it only implements IWorkable. This is ISP working together with LSP.

2. Composition over inheritance. If a subclass can't truly substitute for its parent, don't use inheritance. Have the class contain the other as a private field and expose only the operations it can actually support. Stack has-a List rather than inherits from List.

3. Result pattern. If some implementations might fail where others succeed, make failure an explicit part of the contract. Return Result<T> with Success/Failure instead of throwing surprise exceptions. Now every caller handles failure uniformly.

Think of IReadOnlyList<T> like a one-way mirror. From your side (through the interface), you can only look, not touch. But someone on the other side (holding the original List<T> reference) can still rearrange, add, and remove items. You just can't see the mutation methods. The underlying collection IS still mutable.

ImmutableList<T> (from System.Collections.Immutable) is more like a photograph. The data is frozen in time. Nobody can change it, from any reference. If someone "adds" an item, they get a brand-new list; the original stays unchanged. For truly safe code, especially in multi-threaded scenarios, ImmutableList<T> provides the guarantee that IReadOnlyList<T> merely implies.

Generic variance is the compiler's way of enforcing LSP at the type level. It answers the question: "If Dog is a subtype of Animal, is IEnumerable<Dog> a subtype of IEnumerable<Animal>?" The answer depends on how the generic type is used.

Covariance (the out keyword) means "this type parameter only comes OUT of the interface." IEnumerable<out T> only produces T values (via GetEnumerator). Since every Dog is an Animal, reading Dogs and treating them as Animals is always safe. So IEnumerable<Dog> can substitute for IEnumerable<Animal>.

Contravariance (the in keyword) means "this type parameter only goes IN to the interface." IComparer<in T> only consumes T values. A comparer that knows how to compare any Animal certainly knows how to compare Dogs. So IComparer<Animal> can substitute for IComparer<Dog>.

IList<T> is invariant because T goes both in and out. If you could treat IList<Dog> as IList<Animal>, someone could add a Cat to your list of Dogs. The compiler prevents this.

Contract tests are the most practical way to enforce LSP in a real codebase. The idea is simple: write one set of tests that verifies the interface's promises, then run those exact same tests against every implementation.

You create an abstract test class with all the contract tests: "save then get returns the saved value," "get non-existent returns null," "delete removes the item," etc. Then for each implementation, you create a thin concrete test class that just provides the specific implementation to test. Every implementation runs the exact same test suite.

// Abstract contract test — defines WHAT the interface must do
public abstract class IOrderRepositoryContractTests
{
    protected abstract IOrderRepository CreateSut();

    [Fact]
    public async Task SaveThenGet_ReturnsSavedOrder()
    {
        var sut = CreateSut();
        var order = new Order { Id = 1, Total = 99.99m };
        await sut.SaveAsync(order);
        var result = await sut.GetByIdAsync(1);
        Assert.Equal(order.Total, result!.Total);
    }

    [Fact]
    public async Task GetNonExistent_ReturnsNull()
    {
        var sut = CreateSut();
        var result = await sut.GetByIdAsync(999);
        Assert.Null(result);
    }
}

// Concrete tests — one per implementation
public class SqlRepoTests : IOrderRepositoryContractTests
{
    protected override IOrderRepository CreateSut() => new SqlOrderRepository(_db);
}

public class CachedRepoTests : IOrderRepositoryContractTests
{
    protected override IOrderRepository CreateSut() => new CachedOrderRepository(_inner);
}

If any implementation fails any contract test, it violates LSP. The beauty is that this catches violations automatically: when someone adds a new implementation, they just need to create one more concrete test class and all contract tests run against it.

Yes, in most cases it is. If an interface says "this method works," and your implementation says "nope, not supported," you've broken the contract. The caller expected the method to do something useful, and instead it blew up.

However, there's a pragmatic exception. If the interface contract explicitly says "this method MAY throw NotSupportedException, check the capability flag first," then the exception is part of the documented contract, not a surprise. .NET's Stream class does this: Seek() might throw, but the contract says "check CanSeek first." That's not ideal, but it's a managed violation with clear documentation.

The best fix is to split the interface. Instead of one fat IStream with Read/Write/Seek, create IReadableStream, IWritableStream, and ISeekableStream. Each implementation only promises what it can deliver. No exceptions needed.

The problem with exceptions is unpredictability. One implementation succeeds, another throws ArgumentException, and a third throws TimeoutException. The caller has no way to know what to expect because the contract doesn't mention exceptions. This is a postcondition violation: different implementations have different failure modes.

The Result pattern fixes this by making failure an explicit part of the return type. Instead of returning Order or throwing, every implementation returns Result<Order>. This type has two states: Success (with the order) or Failure (with an error message). Now every implementation honors the same contract: "I always return a Result, and you check IsSuccess."

// Contract: always returns Result, never throws
public interface IPaymentProcessor
{
    Task<Result<PaymentReceipt>> ChargeAsync(decimal amount);
}

// Both implementations honor the same contract
public class StripeProcessor : IPaymentProcessor
{
    public async Task<Result<PaymentReceipt>> ChargeAsync(decimal amount)
    {
        try { /* ... */ return Result.Ok(receipt); }
        catch (StripeException ex) { return Result.Fail(ex.Message); }
    }
}

// Caller — works identically for ALL implementations
var result = await processor.ChargeAsync(99.99m);
if (result.IsSuccess) ShowReceipt(result.Value);
else ShowError(result.Error);

No surprise exceptions, no special catch blocks for specific implementations. Every processor is truly interchangeable because the contract explicitly includes both success and failure.

IQueryable<T> inherits from IEnumerable<T>. Since it's a subtype, every LINQ method that works on IEnumerable should also work on IQueryable. But IQueryable translates LINQ expressions to SQL, and SQL doesn't support everything C# does.

For example, .Last() works fine on any IEnumerable (just iterate to the end). But EF Core's IQueryable can't translate .Last() to SQL because most databases don't have a "give me the last row without ordering" concept. Calling .Last() throws a runtime exception. Similarly, calling .Where(x => MyCustomMethod(x)) fails because EF Core can't translate your custom C# method into SQL.

The fix: don't expose raw IQueryable from your repositories. Instead, use the Repository pattern with explicit methods like GetByIdAsync() and GetPagedAsync(). The LINQ translation happens inside the repository, where you control which operations are used.

Yes. A sealed class can't be inherited from, so it can't have LSP violations through class inheritance. But sealed doesn't prevent it from implementing interfaces incorrectly. If you write sealed class StubLogger : ILogger and the Log() method silently drops all messages, that violates the ILogger contract ("messages are logged").

The sealed keyword prevents one source of LSP issues (subclassing surprises) but not the other (interface contract violations). In fact, the .NET performance guidelines recommend making classes sealed by default because it enables JIT devirtualization and communicates "this class is not designed for inheritance." But you still need to make sure the sealed class honors every interface it claims to implement.

Immutability is the single most effective tool for preventing LSP violations. Think about it: the Square/Rectangle problem only exists because Rectangle has mutable setters that Square overrides with surprising behavior. The read-only list bug only exists because the underlying collection is mutable. The cached repository bug only exists because cached objects are mutable.

With C# records, you get immutability by default. record Rectangle(int Width, int Height) has no setters. "Resizing" creates a new instance with with { Width = 10 }, leaving the original unchanged. There's nothing to override, nothing to mutate, nothing to surprise the caller. If every type in your hierarchy is immutable, an entire category of LSP violations simply cannot exist.

// Immutable records — LSP violations through mutation are impossible
public record Rectangle(int Width, int Height)
{
    public int Area => Width * Height;
}

public record Square(int Side)
{
    public int Area => Side * Side;
}

// "Resizing" creates new instances — originals never change
var rect = new Rectangle(5, 10);
var taller = rect with { Height = 20 };  // New object, rect unchanged
// No setters to override, no mutation surprises

Method hiding with new creates a situation where the same object behaves differently depending on the reference type you use to hold it. If you hold a Derived reference, you call Derived.Method(). If you cast it to Base, you call Base.Method(). Same object, two different behaviors.

This isn't technically an LSP violation in the strictest sense (when you hold a Base reference, you DO get Base's behavior, which is correct for the Base type). But it defeats the purpose of polymorphism entirely. The whole point of LSP is that you shouldn't need to care about the actual type behind the reference. Method hiding makes the reference type matter, which creates confusing bugs where behavior changes depending on variable declarations.

The fix: use override instead of new. With override, the runtime type always wins, regardless of the reference type. If the base method isn't virtual and you can't change it, that's a strong signal you shouldn't be inheriting from it.

A decorator wraps another implementation of the same interface, adding behavior (logging, caching, retrying) without changing the contract. Since the decorator IS a subtype (it implements the same interface), it must honor the same promises.

A logging decorator should add log statements but return the exact same values as the wrapped instance. A caching decorator should return correct data and invalidate the cache when writes happen. A retry decorator should be transparent: if all retries fail, it throws the same exception type the original would have thrown.

Common mistakes that break LSP in decorators: (1) A caching decorator that returns stale data because it doesn't invalidate on writes. (2) A retry decorator that swallows exceptions and returns a default value. (3) A logging decorator that catches exceptions to log them but forgets to re-throw, silently swallowing errors.

public class LoggingOrderRepository : IOrderRepository
{
    private readonly IOrderRepository _inner;
    private readonly ILogger _logger;

    public async Task<Order?> GetByIdAsync(int id)
    {
        _logger.LogInformation("Getting order {Id}", id);
        var result = await _inner.GetByIdAsync(id);  // ✅ Same return value
        _logger.LogInformation("Got order {Id}: {Found}", id, result != null);
        return result;  // ✅ No transformation, no swallowing
    }
}

ISP (Interface Segregation Principle) is LSP's best friend. ISP says "don't force classes to implement methods they can't use." LSP says "every method you implement must work correctly." When an interface is too broad, implementations are forced to stub out methods with throw new NotSupportedException(), which violates LSP.

For example, an IWorker interface with Work() and Eat() forces a Robot class to implement Eat(). A robot can't eat, so it throws. That's an LSP violation. The ISP fix: split into IWorkable and IFeedable. Robot only implements IWorkable. Now there's no method it can't honor, and LSP is satisfied.

Think of ISP as a preventive measure: it eliminates the situations that would force LSP violations. If you're constantly finding LSP violations in your codebase, the root cause is often interfaces that are too fat (ISP violation).

The Object base class defines three mathematical properties for Equals and one critical rule linking it to GetHashCode. Testing all four is your way of ensuring LSP compliance:

1. Reflexive: x.Equals(x) must always be true. 2. Symmetric: if x.Equals(y) then y.Equals(x). 3. Transitive: if x.Equals(y) and y.Equals(z), then x.Equals(z). 4. Hash code consistency: if x.Equals(y), then x.GetHashCode() == y.GetHashCode().

[Theory, MemberData(nameof(EqualPairs))]
public void Equals_IsSymmetric(User x, User y)
{
    Assert.Equal(x.Equals(y), y.Equals(x));
}

[Theory, MemberData(nameof(EqualPairs))]
public void EqualObjects_HaveSameHashCode(User x, User y)
{
    if (x.Equals(y))
        Assert.Equal(x.GetHashCode(), y.GetHashCode());
}

// Best approach: property-based testing with FsCheck
[Property]
public Property HashCode_ConsistentWithEquals(User x, User y) =>
    (x.Equals(y) == false || x.GetHashCode() == y.GetHashCode()).ToProperty();

Property-based testing with FsCheckA .NET port of Haskell's QuickCheck library. Instead of writing individual test cases, you define properties that must always hold (e.g., "sorting is idempotent") and FsCheck generates hundreds of random inputs to try to find a counterexample. Excellent for testing mathematical contracts like equality and comparison. is ideal here because it generates hundreds of random inputs and checks that all properties hold, instead of relying on you to think of every edge case.

Async methods add several hidden postconditions that implementations must honor. The return type is Task<T>, which carries expectations beyond just "eventually returns a value."

Rule 1: Don't block. If the interface returns Task<T>, callers expect to await it without blocking. An implementation that internally calls .Result or .Wait() can deadlock in ASP.NET or UI contexts. That's a postcondition violation: the caller expected a non-blocking operation and got a deadlock.

Rule 2: Exceptions go in the Task. Async methods should wrap exceptions inside the returned Task (which happens automatically with async/await). If an implementation throws synchronously before the first await, the exception escapes the Task and callers who try-catch the await won't catch it.

Rule 3: Honor cancellation tokens. If the contract includes CancellationToken ct, implementations must periodically check ct.IsCancellationRequested or pass the token to downstream calls. An implementation that ignores the token strengthens the precondition: "I only work without cancellation." Code that depends on timely cancellation (like HTTP request timeouts) will hang.

public interface IDataFetcher
{
    Task<Data> FetchAsync(string url, CancellationToken ct);
}

// ❌ BAD: Blocks, ignores cancellation, throws synchronously
public class BadFetcher : IDataFetcher
{
    public Task<Data> FetchAsync(string url, CancellationToken ct)
    {
        if (url == null) throw new ArgumentNullException();  // ❌ Sync throw
        var result = _http.GetAsync(url).Result;             // ❌ Blocking
        return Task.FromResult(Parse(result));               // ❌ Ignores ct
    }
}

// ✅ GOOD: Truly async, honors cancellation, exception in Task
public class GoodFetcher : IDataFetcher
{
    public async Task<Data> FetchAsync(string url, CancellationToken ct)
    {
        var response = await _http.GetAsync(url, ct);  // ✅ Async + ct
        ct.ThrowIfCancellationRequested();              // ✅ Checks ct
        return Parse(await response.Content.ReadAsStringAsync(ct));
    }
}

When you register multiple implementations of the same interface (like IEnumerable<INotificationChannel>), each implementation is a subtype that must honor the interface contract. The system iterates through all of them, calling the same method on each. If any one behaves differently, the whole pipeline is affected.

The most common LSP violation here is performance asymmetry. If SmsChannel.SendAsync() takes 100ms but EmailChannel.SendAsync() takes 5 seconds, the overall pipeline is bound by the slowest channel. Code that loops through all channels and awaits each one will be unexpectedly slow.

The LSP-safe approach: define explicit SLA postconditions in the interface documentation ("SendAsync must complete within 2 seconds or return a failure result"). Then write contract tests that assert timing for each implementation. If Email is inherently slow, it should return a "queued" result immediately and process in the background.

Structs can't inherit from other structs, so the classic inheritance-based LSP violations don't apply. But structs CAN implement interfaces, and that's where a subtle trap lurks: boxing.

When a struct is cast to an interface, C# creates a boxed copy on the heap. If the struct implements IDisposable and you cast it to IDisposable before calling Dispose(), you're disposing the copy, not the original. The original struct's resources are never released. The interface contract says "calling Dispose releases resources," but boxing breaks this guarantee.

public struct FileHandle : IDisposable
{
    private IntPtr _handle;
    public void Dispose() => CloseHandle(_handle);
}

var handle = new FileHandle();
IDisposable disposable = handle;  // ← BOXING: creates a copy!
disposable.Dispose();              // Disposes the COPY
// Original 'handle' is NOT disposed — resource leak!

The fix: avoid implementing IDisposable on structs, or use the using statement directly with the struct variable (which avoids boxing in modern C#). This is why .NET's own ValueTask exists as a struct but uses special compiler support to avoid boxing issues.

Event handlers follow an implicit contract: receive the event, process it, and don't throw. If one handler in a multicast delegateIn C#, events use multicast delegates that can have multiple subscribers. When the event fires, each subscriber's handler is called in order. If any handler throws an exception, the remaining handlers in the chain never execute. throws an exception, all remaining handlers in the chain are skipped. This violates the implicit postcondition that "all subscribers are notified."

This is an LSP issue because each event handler is a "subtype" of the handler delegate contract. The contract says "handle this event." A handler that throws instead of handling breaks the contract and affects every other handler in the chain.

The fix: wrap each handler invocation in a try/catch so one failure doesn't cascade. Or better yet, use an event aggregator (like MediatR) that isolates handler failures. In MediatR, pipeline behaviors should catch and log exceptions from individual handlers without letting them crash the entire notification pipeline.

Designing for LSP compliance is about discipline at the beginning, not fixes at the end. Three rules will save you:

1. Contract first. Before writing any implementation, write down what the base type promises. What inputs does it accept? What does it guarantee about outputs? What invariants must always hold? Write these as XML doc comments or, better, as contract tests.

2. Tests before subtypes. Write the contract test suite (see Q9) before creating any subtype. The tests define the behavioral specification. Any future implementation that passes all tests is LSP-compliant by definition.

3. The type-check smell. If you find yourself writing if (x is SpecificSubtype) in caller code, that's a red flag. It means the subtype isn't truly substitutable and the caller needs special handling. Either fix the subtype's behavior or restructure the hierarchy.

/// <summary>Payment processor contract.</summary>
/// <remarks>
/// Preconditions: amount > 0, currency is valid ISO code
/// Postconditions: returns Result (never throws), completes within 5s
/// Invariants: idempotent — charging same orderId twice = one charge
/// </remarks>
public interface IPaymentProcessor
{
    Task<Result<Receipt>> ChargeAsync(
        decimal amount, string currency, string orderId,
        CancellationToken ct);
}

// Now write contract tests BEFORE any implementation:
[Fact] public async Task Charge_NegativeAmount_ReturnsFailure() { /* ... */ }
[Fact] public async Task Charge_SameOrderTwice_IsIdempotent() { /* ... */ }
[Fact] public async Task Charge_CompletesWithinFiveSeconds() { /* ... */ }

DIP and LSP are two halves of the same coin. DIP says "depend on abstractions (interfaces), not concrete classes." LSP says "every concrete class that implements that interface must actually behave the way the interface promises."

DIP without LSP is dangerous. You refactor your code to depend on IRepository instead of SqlRepository. Great, now you can swap implementations. But if the new MongoRepository doesn't honor the same contract (returns items in a different order, throws different exceptions, doesn't support transactions), your code breaks. You've got the abstraction layer that DIP wanted, but the implementations aren't trustworthy.

Together, DIP gives you the abstraction layer, and LSP guarantees that swapping implementations doesn't break anything. This is the foundation of reliable dependency injection: you can confidently register services.AddScoped<IRepository, AnyRepo>() because LSP ensures AnyRepo plays by the rules.

API versioningThe practice of maintaining multiple versions of an API (v1, v2) to allow clients to migrate gradually. Each new version is essentially a "subtype" of the API contract — it must honor existing expectations (backward compatibility) while adding new capabilities. is LSP applied at the service boundary instead of the class boundary. A v2 API is essentially a "subtype" of the v1 API. Clients that worked with v1 should continue to work with v2 without changes. That's substitutability across HTTP.

The LSP rules map directly: a v2 endpoint that requires new mandatory parameters strengthens the precondition (clients must send more data). A v2 that returns fewer response fields weakens the postcondition (clients get less than they expected). Both are breaking changes that violate backward compatibility, which is LSP for APIs.

Safe API evolution follows LSP: add optional request fields (weaker preconditions, accepting more), add new response fields (stronger postconditions, giving more), add new endpoints (extending without modifying). Never remove response fields or make request fields mandatory in an existing version.

Implicit postconditions are the sneaky ones. The interface doesn't say "must complete within 100ms," but every caller assumes it. When a new implementation takes 5 seconds instead of 5 milliseconds, the system breaks even though the return value is correct.

The most practical approach is to add performance assertions to your contract tests. Measure execution time with a Stopwatch and assert it's within acceptable bounds. For more rigorous testing, use BenchmarkDotNetA popular .NET benchmarking library that provides statistically rigorous performance measurements. It handles warm-up, multiple iterations, and statistical analysis automatically, giving you reliable baseline metrics for each implementation. to establish baseline metrics for each implementation and flag regressions in CI.

// Add to your contract test suite
[Fact]
public async Task GetByIdAsync_CompletesWithinSLA()
{
    var sut = CreateSut();
    await sut.SaveAsync(new Order { Id = 1, Total = 99m });

    var sw = Stopwatch.StartNew();
    await sut.GetByIdAsync(1);
    sw.Stop();

    Assert.True(sw.Elapsed < TimeSpan.FromMilliseconds(100),
        $"GetByIdAsync took {sw.ElapsedMilliseconds}ms — SLA is 100ms");
}

If a new caching decorator or database migration makes the hot path 10x slower, this test catches it before production. Make implicit postconditions explicit by testing them.

These are two different ways to decide whether one type can substitute for another.

Structural subtyping (TypeScript's approach, often called "duck typing") only checks the shape: if an object has the right methods with the right signatures, it's a subtype. A class with a Sort(IList<T> items) method structurally matches ISortStrategy, even if the method arranges items randomly instead of sorting them.

Behavioral subtyping (LSP) goes deeper: it checks that the methods actually behave correctly. Having a Sort() method isn't enough; the method must actually sort. Having a Save() method isn't enough; the method must actually persist data.

C# uses nominal typing: you must explicitly say class MySort : ISortStrategy. This is stronger than structural typing (you can't accidentally satisfy an interface) but weaker than behavioral typing (the compiler can't check that Sort() actually sorts). LSP fills that gap: it's a design principle that says "make sure your implementations actually do what the interface promises," which no compiler can fully enforce.

Default interface methodsA C# 8+ feature that allows interfaces to provide method implementations. Existing classes that implement the interface don't need to change — they get the default behavior automatically. This is LSP-friendly because it adds capabilities without breaking existing subtypes. are inherently LSP-friendly. They let you add new methods to an interface without breaking existing implementations. Before C# 8, adding a method to IRepository would break every class that implements it. With default methods, existing classes get the default behavior automatically.

The LSP risk comes when an implementation overrides the default with different semantics. If the default BulkSaveAsync() saves items one by one (safe but slow), and an override saves them in a transaction (fast but different failure mode), callers who depend on the default's "one item fails, others succeed" behavior will get a surprise when the override rolls back everything.

public interface IRepository<T>
{
    Task SaveAsync(T entity);

    // Default method: safe, LSP-friendly addition
    async Task BulkSaveAsync(IEnumerable<T> entities)
    {
        foreach (var entity in entities)
            await SaveAsync(entity);  // One at a time — partial success possible
    }
}

// Override must honor the SAME contract as the default
public class SqlRepo : IRepository<Order>
{
    public async Task BulkSaveAsync(IEnumerable<Order> entities)
    {
        // ⚠️ Wraps in a transaction — ALL or NOTHING
        // This changes the failure semantics! LSP risk.
        using var tx = await _db.BeginTransactionAsync();
        // ...
    }
}

The safest approach: run your contract tests against both the default behavior AND any overrides. If the override changes the observable behavior (not just performance), document the difference clearly.

Sometimes perfect LSP compliance costs more than it's worth. The .NET team knew that Stream violates LSP (NetworkStream can't Seek), but splitting Stream into 7 granular interfaces would make the API unusable. Instead, they chose a managed violation with capability flags.

Pragmatic LSP violations are acceptable when three conditions are met:

1. Documented. The violation is explicitly stated in documentation, XML comments, or capability flags. Nobody should be surprised.

2. Contained. All callers know about it and check for it. If CanSeek is false, nobody calls Seek(). The violation is isolated, not hidden.

3. Tested. There are tests that verify the capability flags are correct and that callers handle both cases (can and can't). If someone accidentally changes CanSeek to return true when it shouldn't, a test catches it.

The key distinction: accidental LSP violations are always bugs. Conscious, documented, tested LSP violations are engineering tradeoffs. The question isn't "is this a violation?" but "is this violation managed or wild?"