Пример нарушения Liskov Substitution Principle (LSP) из реального продакшена может выглядеть так:

Есть базовый класс PaymentProcessor с методом processPayment(amount), который обрабатывает платеж.

public class PaymentProcessor {
    public void processPayment(double amount) {
        // Общая логика обработки платежа
    }
}

Подкласс FreePaymentProcessor предназначен для бесплатных услуг и переопределяет метод, но не выполняет обработку, а выбрасывает исключение:

public class FreePaymentProcessor extends PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        throw new UnsupportedOperationException("Free payments are not processed");
    }
}

Это нарушение LSP, так как клиент, использующий PaymentProcessor, ожидает, что любой подкласс сможет корректно обработать платеж, а тут подкласс ломает контракт, выбрасывая исключение. В продакшене это может привести к неожиданным сбоям.

Правильнее было бы пересмотреть иерархию или использовать композицию, чтобы не создавать подклассы, которые не поддерживают базовый функционал.

Приведите более реалистичный пример нарушения LSP из продакшена.