Я читав, що принцип заміни Ліскова порушується, якщо:
Передумови посилюються, або
Послідовності ослаблені
Але я ще не розумію, як ці два пункти порушили б принцип заміни Ліскова. Може хтось, будь-ласка, поясніть на прикладі. Зокрема, як будь-яка з перерахованих вище умов спричинить ситуацію, коли об'єкт підкласу не може бути замінений об’єктом надкласового класу?
Відповіді:
Припустимо, що ваша базова робота працює з int-членом. Тепер ваш підтип вимагає, щоб цей int був позитивним. Це посилено попередні умови, і тепер будь-який код, який працював ідеально раніше, з негативними входами, порушений.
Так само припустімо той самий сценарій, але базовий клас використовувався для гарантії того, що член буде позитивним після виклику. Потім підтип змінює поведінку, щоб дозволити негативні вставки. Код, який працює на об’єкт (і передбачає, що пост-умова є позитивним int), тепер порушено, оскільки пост-умова не підтримується.
Це, звичайно, банальні приклади, але ця концепція справедлива. Такі речі, як залишення файлу / бази даних відкритим, є прикладом полегшеного стану, що призводить до проблем.
Інваріант - Шаблон SelfDrivingVehicle, який залишається незмінним у всіх підтипах, тобто Порядку, в якому він виконує переменені поведінки, щоб досягти місця призначення.
Тут припустимо ще один метод
-List<SelfDrivingVehicle> vehicles
+Add(SelfDrivingVehicle vehicle)
vehicles.add(vehicle)
Попередня умова - SelfDriveVehicle Базового типу в ньому немає транспортних засобів (тут контекст - Додати), і його в Ослабленому передумові, який не може бути змінено жодним із його підтипів, змінивши властивості транспортного засобу та явно підсилити його. Будь-який із підтипів може викликати лише Додати.
Пост-умова - Після виклику "Додати" базовий тип знаходиться в Посиленій посткондиціоні, яку неможливо ослабити за підтипами, змінивши значення транспортних засобів.
Стан базового типу повертається до початкового стану після виклику Add Behavior.
Цей приклад досить сильно побитий, але врахуйте можливість Площа / Прямокутник або Коло / Еліпс. Припустимо, у вас базовий клас Прямокутник, який визначає об'єкт довжиною і шириною. Якщо у вас клас Square, який успадковує клас Rectangle, у його setter / getter буде встановлено правило, яке вимагає, щоб будь-яка зміна довжини чи ширини змінила його аналог. Ці вимоги до розмірів посилюють попередні умови, оскільки у прямокутнику, заміщеному на квадрат, відсутні б ці вимоги до розмірів. Припустимо, ви обернете спадщину таким чином, щоб прямокутник успадковував квадрат, ви послабили б умови посту, послабивши вимоги до розмірів, щоб дозволити прямокутнику вести себе незалежно.
Однак, якщо вам потрібно було зняти можливість зміни розмірів, принцип заміщення дотримується, оскільки якщо ні прямокутник, ні квадрат не можуть змінити розміри, то вони мають рівні умови до і після, незалежно від успадкування. Обидва мають довжину, обидві мають ширину, і жодне не може змінити ці значення.
ref: Wikipedia - http://en.wikipedia.org/wiki/Liskov_substitution_principle