Все, що ви хотіли знати про принципи SOLID. Частина третя: LSP

Вітаю, друзі! З вами знову Сергій Немчинський — програміст з понад 20-річним досвідом розробки та засновник навчального центру FoxmindEd.

Нагадую, що я прагну зробити світ програмування кращим. Для цього потрібно більше професійних розробників, які пишуть чистий та якісний код. Щоб сприяти цьому, я працюю над серією статей про принципи SOLID та покращення світу програмування з їх допомогою.

Знов-таки нагадую, що критика принципів SOLID та концепції чистого коду має право на існування, в тому числі в коментарях. Але перш ніж щось критикувати, треба з’ясувати, що саме ми критикуємо та чому. Так створюються об’єктивні професійні погляди.

Сьогодні пропоную вашій увазі третю статтю циклу, яка описує принцип Liskov Substitution Principle, він же LSP.

В попередніх серіях

Для тих, хто пропустив перші дві статті, коротко нагадаю їх зміст. Принципи SOLID були зібрані й систематизовані Робертом Мартіном. SOLID — це акронім, кожна літера — початок назви одного з принципів.

Ми вже розглянули принцип єдиної відповідальності (Single Responsibility Principle) та принцип відкритості-закритості (Open-Closed Principle) — літери S та O відповідно. Настав час для Liskov Substitution Principle, літера L. Цей принцип, названий на честь Барбари Лісков, є єдиним з п’яти принципів SOLID, що носить ім’я людини.

Історія та формулювання

Спочатку трохи про авторку принципу. Барбара Лісков — видатна американська науковиця та винахідниця у галузі комп’ютерних наук, перша жінка-професорка інженерного факультету MIT — інституту технологій в Массачусетсі, який вважається головним технічним ВНЗ у світі. Лісков розробила CLU — революційну мову програмування, що вплинула на розвиток Java, C++ та інших сучасних мов. Також вона є лауреаткою премії Тюрінга 2008 року, це аналог Нобелівки в програмуванні.

Окрім того, що наукові роботи Лісков змінили підхід до проєктування програмного забезпечення, вона ще створила «ефект Скаллі» в IT-індустрії, надихнувши ціле покоління дослідниць і розробниць.

І ось ця видатна жінка сформулювала принцип підстановки, або Substitution, таким чином:

У тому випадку, якщо Q від X властивість вірована щодо об’єктів X деякого типу T, то властивість Q від Y також буде вірною відносно ряду об’єктів Y, які відносяться до типу S, при цьому S підтип якогось типу T.

Сподіваюсь, що серед читачів статті знайдуться ті, кому це формулювання зрозуміло без додаткових пояснень. Я до них не належу. На моє (і не лише моє) щастя Роберт Мартін, який систематизував принципи SOLID, запропонував простіше формулювання:

«Функції, які використовують базовий тип, повинні мати можливість використовувати підтипи базового типу, не знаючи про це.»

Ще простіше можна сказати: поведінка в похідних класах не повинна суперечити поведінці, заданій базовим класом.

Принцип підстановки Лісков на прикладі без коду

Уявіть собі компанію з автоматизованим складом, де використовуються різні типи транспортних роботів. У компанії є базова модель робота-транспортувальника зі стандартними функціями: «підняти вантаж», «рухатися до точки», «опустити вантаж». Усі ці функції чітко описані в інструкції з експлуатації, і всі працівники знають, як цими роботами керувати.

Компанія купила нову, покращену модель роботів-транспортувальників з додатковим функціоналом. Якщо ПЗ нових роботів повністю відповідає принципу підстановки Лісков, то все працює, як раніше. Наприклад, набір команд «підняти вантаж» — «рухатися до точки А» — «опустити вантаж» призводить до того, що робот підіймає, переміщує та опускає вантаж в точці А.

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

Якщо в цьому місці вам стало боляче, ви теж стикалися з продуктами, в яких принцип Лісков було порушено. Це нормально, і саме тому ми про це говоримо — таких порушень має бути якнайменше.

Приклади порушення LSP в житті програмістів

Сподіваюсь, основну ідею принципу LSP ви вже зрозуміли. Тепер розкажу, як цей принцип порушується в програмуванні й до чого це призводить.

Невпроваджені методи

У вас є клас, який описує якесь зовнішнє джерело даних, наприклад, якусь Legacy-систему. У класу є купа методів, які використовує ваш клієнтський код. Ви пишете Unit Test, для чого створюєте тестовий об’єкт, він же mock. Вам, звичайно ж, лінь прописувати всі ці методи, тому ви від них успадковуєтесь, але всередині пишете: throw new NotImplementedException, позначаючи свій дочірній клас як виключення. І у вас все працює добре.

А потім приходить інший програміст, створює новий код, бере ваш mock, і пише свій юніт-тест. І у нього все падає з NotImplementedException. Програміст лається, і ми його дуже розуміємо, бо це реально мєрзость. Це звісно не така велика проблема, тому що це юніт-тест і програміст одразу побачить в чому проблема, але якщо так зробити з класом бойового коду, то проблема може вилізти в зовсім несподіваному місці.

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

Додаткові вимоги до клієнтського коду

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

Це також порушення LSP. Ваш клас повинен використовуватися так само.

Повернення NULL

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

Якщо базовий клас повертає повний набір даних, а дочірній клас повертає неповні дані або null — це також порушення LSP. Код, що використовує базовий клас, очікує отримати нормальні дані та не готовий до обробки null або неповних даних. Та і взагалі ніколи не повертайте NULL, але про це окремо, якщо вам буде цікаво.

Прямокутник і квадрат

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

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

Клієнтський код, який очікує, що змінюється тільки одна сторона, буде працювати неправильно з квадратом. Наприклад, якщо встановити спочатку одну сторону 10, а потім іншу 5, то у випадку з квадратом або ви отримаєте те саме not implemented, або значення 10 для другої сторони буде перезаписане новим 5. Це може призвести до несподіваних результатів, наприклад, при обчисленні площі. Тобто або ви отримаєте помилку, або невірні дані.

Як не порушувати LSP

Тільки не кажіть, що ви не використовуєте успадкування, тому й про LSP вам думати не потрібно. Забудьте про це. Якщо ви не використовуєте успадкування, ви не використовуєте об’єктноорієнтоване програмування. Ви криворукий лайнокодер, що пише процедурний код. Мені за вас соромно.

А для всіх інших ось п’ять простих правил, які допоможуть не порушувати принцип підстановки:

1. Переконайтеся, що всі методи дочірнього класу відповідають контрактам базового класу. Якщо ви не можете реалізувати метод, можливо, вам не слід використовувати наслідування.
2. Не кидайте винятки в методах, які перевизначаєте, якщо базовий клас не передбачає цих винятків.
3. Не повертайте null, якщо базовий клас повертає об’єкт. Краще використовуйте шаблон Null Object.
4. Ретельно продумуйте ієрархію класів. Наприклад, у випадку з прямокутником і квадратом, краще не робити квадрат нащадком прямокутника, а створити загальний базовий клас «Фігура» і від нього успадкувати обидва класи.

5. Пишіть тести, які перевіряють відповідність LSP для ваших класів.

Коли можна порушувати LSP

Це ваша улюблена частина: якщо не можна, але дуже хочеться, то трошки можна. Як і будь-який принцип, LSP вимагає розумного дотримання. У деяких випадках повністю дотримуватися принципу може бути складно.

Наприклад, при створенні mock-об’єктів для тестування, коли базовий клас має багато методів, а вам потрібна лише мала їх частина. Добре, тоді пропишіть тут exception. Але пам’ятайте, що так ви трішечки налайнокодили. Тому обов’язково документуйте, що це mock-клас, який порушує LSP і не повинен використовуватися в бойовому коді. Ваші колеги, які працюватимуть з цією системою, вам подякують, і ваша карма не постраждає.

Приклад практичного застосування принципу підстановки Лісков

Продовжимо наш серіал про Петра та Василя з їхньою системою датчиків. Тепер датчики реалізують інтерфейс Sensor з методами getValue(), calibrate() та getUnit(). Система чудово працює з усіма типами датчиків через цей єдиний інтерфейс.

Одного дня Василь приносить новий датчик температури EconomySensor, який споживає менше енергії. Керівництво у захваті, новий датчик миттєво впроваджено. Але після впровадження система починає давати збої: з’явилися помилки під час калібрування, нульові значення на екранах та неправильні розрахунки через різний формат даних про температуру.

Колега Василя Петро сідає за аналіз і з’ясовує, що код датчика:

1. Викидає виняток у методі calibrate() замість виконання калібрування.
2. Вимагає попереднього виклику warmUp() перед getValue(), інакше повертає null.
3. Може повертати значення у «C» або «F» з getUnit() залежно від стану.

Що робить Петро? Пояснює Василю, що його економний датчик порушує принцип Лісков, бо не може коректно замінити базовий тип. І що тепер, нові датчики забирати? Та ні. Досить перепланувати рішення:

1. Переробити calibrate(), щоб виконував пусту операцію без помилок.
2. Автоматично викликати warmUp() всередині getValue().
3. Стандартизувати getUnit(), щоб завжди повертав «C».

Для розширених можливостей можна створити окремий інтерфейс AdvancedSensor з додатковими методами, які працюють з розширеними даними і не порушують основний контракт.

Щасливий Василь отримує бонус, задоволений клієнт підраховує економію, а втомлений Петро витирає піт з лоба.

Висновок

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

Нові, розширені версії ПЗ можуть додавати функціональність, але не можуть змінювати базову поведінку, на яку всі покладаються. Якщо ви використовуєте наслідування, переконайтеся, що дочірні класи можуть повністю замінити батьківські класи без зміни очікуваної поведінки програми. Думайте над своїми ієрархіями класів, не кидайте винятки в перевизначених методах, не повертайте null і не змушуйте клієнтський код вивчати внутрішню структуру ваших класів.

І, звісно, пишіть в коментарях, що ви про це все думаєте.