Насколько актуален принцип подстановки Лисков (LSP) в современных системах?

А, слушай, вот этот ваш принцип подстановки Лисков, ну это ж, блядь, основа основ, а половина пишет код так, будто им в рот чих-пых! Сейчас разжуем, что к чему.

Суть, если по-простому: если у тебя есть какой-то базовый тип, то на его место можно сунуть любой дочерний, и программа не должна от этого взорваться, обосраться или начать вести себя как мартышлюшка с гранатой. Всё должно работать, как часы, ёпта.

Зачем он вообще нужен, этот LSP, в наше время?

1. Без него нихуя не работает:

• Весь полиморфизм — это и есть про замену одного объекта другим. Если принцип нарушен, то вместо красоты ООП получается пиздопроебибна.
• Абстракции и интерфейсы — это контракт. Нарушил LSP — контракт порвал, и теперь тебе доверия ебать ноль.
• Тестирование — когда ты подсовываешь мок вместо реального сервиса, он ДОЛЖЕН вести себя точно так же, иначе твои тесты — хуй с горы.
• Микросервисы — новая версия сервиса должна нахуй заменять старую для клиентов, не ломая их. Иначе это не обновление, а диверсия.

2. Классический пример, где всё пошло по пизде:

Смотри, вот есть класс Rectangle (прямоугольник). У него есть ширина и высота, их можно менять по отдельности.

class Rectangle {
    protected int width;
    protected int height;

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getArea() {
        return width * height;
    }
}

А теперь какой-то умник решил: «А давайте я сделаю квадрат, который наследуется от прямоугольника! Это же логично, квадрат — частный случай!». И вот что выходит:

class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width); // ОЙ, БЛЯДЬ! Побочный эффект!
    }

    @Override
    public void setHeight(int height) {
        super.setHeight(height);
        super.setWidth(height); // ОПЯТЬ ОНО, СУКА!
    }
}

И теперь представь, есть функция, которая работает с прямоугольником:

void resize(Rectangle rectangle) {
    rectangle.setWidth(5);
    rectangle.setHeight(4);
    // Ожидаем площадь 5 * 4 = 20
    assert rectangle.getArea() == 20;
}

Если ты передашь сюда Rectangle — всё ок. Но если передашь Square... Ёперный театр! Он после setWidth(5) автоматом и высоту в 5 поставит. Потом setHeight(4) ширину в 4 поставит. И площадь будет 4 * 4 = 16. Assert провалится, программа поедет крышей. Это и есть нарушение LSP: квадрат не является полноценной заменой прямоугольника в этом контексте. Он меняет ожидаемое поведение.

3. Как надо было сделать, чтобы не было мучительно больно:

Нахуй наследование, если оно ломает логику. Делаем общий интерфейс.

interface Shape {
    int getArea();
}

// Прямоугольник — самостоятельный класс
class Rectangle implements Shape {
    private int width;
    private int height;

    public Rectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public int getArea() {
        return width * height;
    }
}

// Квадрат — тоже самостоятельный класс
class Square implements Shape {
    private int side;

    public Square(int side) {
        this.side = side;
    }

    @Override
    public int getArea() {
        return side * side;
    }
}

Вот теперь они оба — фигуры (Shape), и там, где нужна просто фигура с площадью, их можно подставлять друг вместо друга. LSP соблюдён, все довольны.

4. Где ещё этот принцип вылезает, как хитрая жопа:

В API микросервисов: Новая версия сервиса (UserServiceV2) должна соблюдать контракт старой (UserService). Может добавлять новые поля в ответ, но не может удалять старые или менять их смысл, иначе клиенты, которые на старый контракт заточены, накроются медным тазом.

В стримах: У тебя есть список List<Number>. Туда можно пихнуть и Integer, и Double, и Long. Потому что они все заменяют Number. И когда ты вызываешь Number::doubleValue, всё работает. Это и есть LSP в действии.

5. Как понять, что ты накосячил и нарушил LSP? Признаки:

• Переопределённый метод в наследнике вдруг начинает швырять новые исключения, которых не было у родителя.
• Он возвращает какой-то более узкий тип, хотя клиентский код рассчитывал на что-то более общее.
• У метода появляются побочные эффекты (как в примере с квадратом — поменял ширину, заодно и высоту ебнул).
• Подкласс начинает требовать большего на вход (усиливает предусловия) или гарантировать меньше на выходе (ослабляет постусловия).

6. Чем проверить?

• Статические анализаторы вроде SonarQube могут намекнуть на подозрительное наследование.
• Контрактное программирование — если бы в Java оно было нормально развито.
• Property-based тесты — отличная штука, чтобы нагенерировать кучу данных и проверить, не ведёт ли наследник себя как пидарас шерстяной в ситуациях, где родитель вёл себя прилично.

Итог: LSP — это не про академическую хуйню. Это про то, чтобы твой код не превращался в хрупкое говно, которое развалится от любого чиха. В мире микросервисов и постоянных изменений его важность только растёт. Нарушаешь его — готовься к ночным вызовам, потому что «оно работало, а потом перестало».