Принцип підстановки Барбари Лісков. Про передумови, постумови та інваріанти

class Customer
{
    protected float $account = 0;

    public function putMoneyIntoAccount(int|float $sum): void
    {
        if ($sum < 1) {
            throw new Exception('Ви не можете покласти на рахунок менше 1$');
        }

        $this->account += $sum;
    }
}

class MicroCustomer extends Customer
{
    public function putMoneyIntoAccount(int|float $sum): void
    {
        if ($sum < 1) {
            throw new Exception('Ви не можете покласти на рахунок менше 1$');
        }

        // Посилення передумов - от цього не треба
        if ($sum > 100) { 
            throw new Exception('Ви не можете покласти більше 100$');
        }

        $this->account += $sum;
    }
}

function processDeposit(Customer $customer) {
    $customer->putMoneyIntoAccount(500); // Все ок для Customer
}

// Але якщо передати MicroCustomer - буде exception
processDeposit(new MicroCustomer()); 

// Батьківський клас очікує конкретний тип
class PaymentGateway {
    public function process(CreditCard $payment) { }
}

// Дочірній може прийняти ширший тип
class FlexibleGateway extends PaymentGateway {
    public function process(PaymentMethod $payment) { } // CreditCard є PaymentMethod
}

Простіше кажучи: передумови — це вимоги до клієнта, постумови — це наші обіцянки клієнту.

class Customer
{
    protected Dollars $account;

    public function chargeMoney(Dollars $sum): float
    {
        $result = $this->account - $sum->getAmount();

        if ($result < 0) { // Постумова - гарантуємо що результат не від'ємний
            throw new Exception();
        }

        return $result; // Обіцянка: повертаємо невід'ємне число
    }
}

class VIPCustomer extends Customer
{
    public function chargeMoney(Dollars $sum): float
    {
        $result = $this->account - $sum->getAmount();

        // Пропущена постумова базового класу - результат може бути від'ємним

        return $result; // Порушили обіцянку - можемо повернути від'ємне число
    }
}

​Умовний вираз, що перевіряє результат, є постумовою в базовому класі, а в наслідника її вже нема.

Чому це критично? Клієнтський код покладається на гарантії:

$balance = $customer->chargeMoney($amount);
// Клієнт впевнений що $balance >= 0 (бо це гарантія методу)
$this->displayBalance($balance); // Може впасти якщо від'ємне

Сюди ж можна віднести і «коваріантність», яка дозволяє оголошувати в методі дочірнього класу типом значення, що повертається, підтип того типу (шо?! 😂), який повертає батьківський метод.

На прикладі буде простіше. Тут в методі render() дочірнього класу, JpgImage оголошений типом значення, що повертається, який в свою чергу є підтипом Image, який повертає метод батьківського класу Renderer:

class Image {}
class JpgImage extends Image {}

class Renderer
{
    public function render(): Image
    {
    }
}

class PhotoRenderer extends Renderer
{
    public function render(): JpgImage
    {
    }
}

​️Таким чином в дочірньому класі ми звузили значення, що повертається. Не послабили. Посилили :)

Це безпечно, бо JpgImage — це все ще Image, просто з додатковими можливостями. Клієнтський код, який очікує Image, отримає його (просто більш специфічний).

Інваріантність

Тут має бути трошки простіше.

Всі умови базового класу — також мають бути збережені і в підкласі.

Інваріанти — це деякі умови, які залишаються істинними протягом всього життя об’єкта. Як правило, інваріанти передають внутрішній стан об’єкта.

Важлива різниця:

• Передумови/постумови — про конкретні методи.
• Інваріанти — про стан об’єкта, незалежно від методів.

Наприклад, бізнес-правила базового класу не повинні змінюватись в дочірньому:

class EmailList
{
    private array $emails = [];

    // ІНВАРІАНТ: список містить тільки валідні email
    public function addEmail(string $email): void
    {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidEmailException();
        }
        $this->emails[] = $email;
    }

    public function getEmails(): array
    {
        return $this->emails; // Завжди повертає валідні emails
    }
}

// Якщо дочірній клас додасть метод, який дозволить 
// додати невалідний email - він порушить інваріант

Тут також варто згадати історичні обмеження («правило історії»):

Підклас не повинен створювати нових мутаторів властивостей базового класу.

Якщо базовий клас не передбачав методів для зміни визначених в ньому властивостей, підтип цього класу також не повинен створювати таких методів. Іншими словами, якщо в батьківському класі щось було незмінним (immutable), не робіть це змінним (mutable) в дочірньому.

class Order
{
    private float $totalAmount;
    private string $status = 'pending';

    public function __construct(float $amount)
    {
        $this->totalAmount = $amount;
    }

    public function getTotal(): float
    {
        return $this->totalAmount;
    }

    // Зверніть увагу - немає методу setTotal()
    // Сума замовлення незмінна після створення
}

class EditableOrder extends Order
{
    public function setTotal(float $newAmount): void
    {
        $this->totalAmount = $newAmount; // порушення
    }
}

В такому випадку варто розглянути додавання мутатора в базовий клас або використання композиції замість наслідування.

Exceptions — це теж частина контракту

Про це часто забувають, але LSP стосується і виключень. Підклас не може кидати ширші виключення:

class PaymentProcessor
{
    public function charge(float $amount): void
    {
        if ($amount > $this->limit) {
            throw new PaymentLimitExceededException(); // Специфічний
        }
    }
}

class CustomPaymentProcessor extends PaymentProcessor
{
    public function charge(float $amount): void
    {
        if ($amount > $this->limit) {
            throw new \Exception('Limit exceeded'); // ПОРУШЕННЯ! Ширший exception
        }
    }
}

// Клієнтський код
try {
    $processor->charge(1000);
} catch (PaymentLimitExceededException $e) {
    // Не зловить загальний Exception від CustomPaymentProcessor!
}

Клієнтський код, який ловить PaymentLimitExceededException, не зловить загальний Exception.

Tell, Don’t Ask

Ще одне важливе правило — замість перевірки типу об’єкта, дайте йому самому вирішити, що робити:

// Погано - питаємо про тип (порушення LSP)
if ($account instanceof PremiumAccount) {
    $account->applyPremiumBenefits();
}

// Добре - кажемо що робити (LSP дотримано)
$account->applyBenefits(); // кожен тип сам знає свої benefits

Як це працює в реальному коді?

Замість того щоб робити глибоку ієрархію наслідування і потім боротись з порушеннями LSP, часто краще використовувати композицію.

Проблема з наслідуванням полягає в тому, що ви змушені взяти всю поведінку батьківського класу, навіть ту, яка вам не підходить.

За допомогою композиції ви створюєте новий клас, який використовує потрібну функціональність через делегування:

// Замість наслідування з обмеженнями
interface AccountInterface {
    public function deposit(float $amount): void;
    public function getBalance(): float;
}

class StandardAccount implements AccountInterface {
    // стандартна реалізація
}

class LimitedAccount implements AccountInterface {
    private AccountInterface $account;
    private float $maxDeposit = 100;

    public function __construct(AccountInterface $account) {
        $this->account = $account;
    }

    public function deposit(float $amount): void {
        if ($amount > $this->maxDeposit) {
            throw new LimitExceededException();
        }
        $this->account->deposit($amount); // делегуємо
    }

    // ...
}

// Клієнтський код працює однаково з обома
function processPayment(AccountInterface $account, float $amount) {
    $account->deposit($amount);
    echo "Депозит прийнято";
}

В чому перевага?

• LimitedAccount не порушує жодних правил StandardAccount.
• Ми не змушені перевизначати всі методи.
• Можемо комбінувати різну поведінку.

Висновки

LSP — це не про складні правила типів. Це про передбачувану поведінку. Коли дочірній клас поводиться «як батьківський, тільки краще» — все добре. Коли він починає додавати обмеження або міняти очікувану поведінку — маєте проблему.

Пам’ятайте:

• Передумови — можна послабити (приймати більше), не можна посилити.
• Постумови — можна посилити (гарантувати більше), не можна послабити.
• Інваріанти — не можна змінювати взагалі.
• Поведінка — має залишатись передбачуваною.

І головне — якщо сумніваєтесь, використовуйте композицію замість наслідування. Це вирішує 90% проблем з LSP 😊