Хто від кого походить

У темі 25 ми навчилися описувати власні типи: class, __init__, self, атрибути примірника проти атрибутів класу — і закінчили на конкретному питанні. У журналі трапляються не лише продажі, а й повернення: майже ті самі поля, майже ті самі методи, але сума зі знаком мінус і перевірки трохи інші. Копіювати весь клас і правити три рядки — очевидно погана ідея. Ця тема про два способи цього не робити. Перший — наслідування, його знають усі. Другий — композиція, і саме він у більшості випадків правильний, хоч у підручниках стоїть аж у кінці розділу.

Наскрізний приклад теми — не журнал продажів, а каталог невеликої бібліотеки, і причина конкретна: у каталозі є те, чого на парі «продаж — повернення» не побачиш. Спершу наслідування виглядатиме бездоганно, а потім ми додамо одну звичайну вимогу — і воно розсиплеться просто на очах.

01 / ДублюванняТри майже однакові класи

Почнемо з коду, який ще нічого не наслідує. Бібліотека видає читачам книги й журнали. Обидва мають назву, рік і вміють коротко себе описати:

Три рядки в __init__ повторюються дослівно. Поки їх три — не страшно. Але каталог живе роками: завтра до кожного видання додасться інвентарний номер, післязавтра — дата надходження, а ще пізніше — метод вік(), який рахує, скільки років виданню. І щоразу правку доведеться вносити у два місця. Не «незручно» — саме у два місця, а це означає, що рано чи пізно хтось виправить одне й забуде друге.

Чому це гірше, ніж просто зайві рядки:

• Правка розповзається. Одна зміна вимоги — кілька місць у коді, і жоден інструмент не підкаже, що ти пропустив одне.
• Класи розходяться непомітно. У Книга хтось додав перевірку року, у Журнал — ні. Тепер вони начебто однакові, а поводяться по-різному.
• Спільну поведінку неможливо назвати. Немає жодного місця в коді, де було б написано: «усе, що видає бібліотека, має назву й рік».

Наслідування (inheritance) розвʼязує саме це: воно дає спільній частині одне імʼя й одне місце.

02 / ІєрархіяБазовий і похідний клас

Виносимо спільне у клас Видання, а Книга й Журнал оголошуємо його різновидами. Синтаксис — назва батьківського класу в дужках після імені:

Слово pass тут означає «тіло порожнє»: Книга поки що не додає нічого свого. І цього вже достатньо, щоб вона працювала:

Ми не писали в Книга ані __init__, ані опис, ані вік — а вони є. Назви для сторін відносини стандартні й вживаються як синоніми:

Важливе уточнення про те, що саме успадковується. Успадковуються методи, а не дані. У класі Видання немає атрибута назва — він зʼявляється в конкретному обʼєкті в момент, коли виконується рядок self.назва = назва. Успадкований __init__ — це просто метод, який запускається на нашому обʼєкті й записує атрибути в нього. Плутанина тут коштує дорого: новачки часто думають, ніби нащадок «отримує копію» батьківських полів. Ніякої копії немає — є один обʼєкт і спільний код, що його наповнює.

Тепер додамо третій рівень — аудіокнигу, яка є різновидом книги:

Про super() буде окремий розділ; поки що читай його як «те саме, але з класу вище». А спершу — головне питання теми.

03 / ПошукДе Python шукає метод

Коли ти пишеш аудіокнига.опис(), Python не знає наперед, у якому класі цей метод лежить. Він шукає — і робить це рівно так само, як шукав імена в темі 15 за правилом LEGB: іде по фіксованому списку місць і зупиняється на першому ж, де знайшов.

Список місць називається MRO (method resolution order — порядок розвʼязання методів). Побачити його можна прямо:

Чотири класи, чіткий порядок: сам клас, потім батько, потім дід, потім object — корінь, від якого походять геть усі класи Python, навіть якщо ти нічого не писав у дужках. Пошук атрибута йде цим кортежем зліва направо. Не знайшов ніде — AttributeError, повний аналог NameError з теми 15.

Два наслідки, які варто зафіксувати одразу.

Перший знайдений виграє, решта не розглядається. Python не збирає всі версії методу й не обирає «кращу». Якщо Аудіокнига має свій опис, версії з Книга й Видання для неї просто не існує — доки ти не покличеш їх явно.

Пошук іде по класу обʼєкта, а не по тексту, де стоїть виклик. Функція, що приймає видання й кличе видання.опис(), отримає різний результат для книги й для журналу — і при цьому в її власному коді немає жодного if. Це і є поліморфізм (polymorphism): один рядок виклику, різна поведінка залежно від того, що прийшло.

04 / ЗамінаПеревизначення

Оголосити в похідному класі метод з тим самим імʼям, що в базовому, називається перевизначенням (overriding). Ніякого спеціального синтаксису для цього немає — просто пишеш def опис(self), і пошук зупиняється на ньому раніше, ніж дійде до батьківського.

Тут є розвилка, яку новачки часто проходять не в той бік. Перевизначити метод можна двома способами:

• Замінити — написати тіло з нуля, ніби батьківського методу немає.
• Розширити — покликати батьківський через super() і додати до його результату своє.

Різниця здається косметичною, поки формат опису не змінюється. Подивись, що буде, коли зміниться:

Практичне правило: якщо твій метод має зробити те саме плюс ще щось — клич super(). Заміна без виклику батьківського виправдана лише тоді, коли поведінка справді інша, а не «схожа, але з дрібницею».

05 / supersuper() і його ланцюжок

Виклик super().__init__(...) означає: «знайди __init__ у наступному класі списку MRO і виконай його на цьому ж обʼєкті». Ключове слово тут — наступному: не «в батьківському», а саме в наступному, і в наступному розділі ця різниця стане принциповою.

Коли класів три, виклики шикуються в ланцюжок: Аудіокнига.__init__ кличе Книга.__init__, та кличе Видання.__init__. Кожна ланка записує свою частину атрибутів, і обʼєкт наповнюється знизу вгору й назад. Пройди цей ланцюжок кроками — і зніми галочку, щоб побачити класичну поломку:

Звідси проста звичка, яку варто завести назавжди: перший рядок __init__ у похідному класі — це super().__init__(...). Спершу нехай базовий клас доведе обʼєкт до робочого стану, а потім уже додавай своє. Виняток — коли своє потрібно порахувати до виклику базового, і тоді це варто прокоментувати прямо в коді.

06 / Чому саме superЧому не Батько.метод(self)

Той самий результат начебто дає й прямий виклик — узяти метод з класу й передати self руками:

Це не помилка, і в дуже старому коді таке трапляється. Але причин писати super() три, і кожна серйозна.

07 / РомбМножинне наслідування й ромб

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

Візьмімо іншу, ненавчальну ситуацію: бібліотека купила техніку. Є Пристрій, від нього походять Сканер і Принтер, а багатофункціональний пристрій — БФП — є і тим, і тим:

Схема звʼязків утворює ромб: від БФП угору йдуть два шляхи, і обидва сходяться в Пристрій. Звідси й назва — ромбоподібна проблема (diamond problem). Питання просте: коли ми кличемо бфп.запустити(), скільки разів має надрукуватися слово «Пристрій»?

Тепер видно, навіщо MRO влаштований саме так. Він не «дерево», по якому Python ходить угору. Він — плаский список без повторів, побудований за трьома правилами: клас іде раніше за своїх батьків; базові класи йдуть у тому порядку, як записані в дужках; кожен клас у списку рівно один раз. Алгоритм, який це рахує, називається C3-лінеаризацією, і його головна властивість якраз у тому, що super(), ідучи цим списком, зайде в кожен клас ромба точно один раз.

Зверни увагу на найдивніше місце інтерактиву: у Сканер.запустити написано super().запустити(), а виконується Принтер.запустити — хоча Принтер не є базовим для Сканер взагалі. Це не баг: super() означає «наступний у MRO цього обʼєкта», а не «мій батько». Який саме клас виявиться наступним, залежить від класу обʼєкта, на якому метод викликали, тобто визначається не там, де метод написано.

08 / КомпозиціяКомпозиція замість наслідування

Це головний розділ теми. Різниця між двома способами повторного використання коду формулюється двома короткими фразами:

Композиція (composition) — це коли обʼєкт не успадковує поведінку, а тримає інший обʼєкт у своєму атрибуті й звертається до нього. Жодного нового синтаксису: self.носій = носій — ось і вся композиція.

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

Виглядає бездоганно. Три класи, кожен зі своїм як_видати(), усе на місці. А потім приходить бібліотекарка й каже: «ще треба позначати мову — українська чи англійська». І ще: «а подарункові видання видаємо лише в залі». Кожна вимога — новий незалежний вимір, і класи починають множитися:

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

Метод як_видати у Книга нічого не робить сам — він передає роботу тому, хто в цьому розуміється. Це називають делегуванням (delegation), і воно є основною роботою композиції.

Як обрати між ними

Перевірка проста й називається «тест на є»: підстав обидва класи у фразу «A є різновидом B» і послухай, чи не звучить вона дивно.

Другий орієнтир — практичний. Наслідування доречне, коли похідний клас підходить скрізь, де очікують базовий: жоден чужий код, що працює з Видання, не має зламатися, отримавши Книга. Якщо ж нащадок забороняє щось із того, що вміє базовий («у нас книга без року»), або перевизначає метод так, що той повертає геть інше, — це вже не різновид, і краще не наслідувати.

09 / КачкаКачина типізація й isinstance

Якщо композиція розводить класи по різних гілках, постає питання: як тоді написати функцію, що працює і з книгою, і з журналом, і з настільною грою? Перша ідея — перевіряти тип:

isinstance(обʼєкт, Клас) відповідає «так», якщо клас обʼєкта — це Клас або будь-який його нащадок. Тобто питання звучить так: «чи є ти різновидом ось цього?». Але функції насправді байдуже, ким є аргумент, — їй потрібно лише, щоб у нього був метод опис().

Підхід, у якому питають не про рід, а про вміння, називають качиною типізацією (duck typing): якщо щось ходить як качка й крякає як качка, для нашої задачі воно й є качка. У Python це стиль за замовчуванням — просто клич метод:

Це не означає, що isinstance — зло. Він доречний там, де тобі справді потрібен саме тип: розгалуження за типом вхідних даних (рядок чи список), перевірка аргументу на межі бібліотеки, обробка різних гілок у except. Але як спосіб «пустити чи не пустити» він майже завжди зайвий і завжди звужує код.

10 / abcАбстрактний базовий клас

У качиної типізації є слабке місце: якщо хтось напише клас і забуде метод опис, ніхто не помітить цього до першого виклику — можливо, вже в роботі. Модуль abc зі стандартної бібліотеки дозволяє сказати прямо: «цей метод зобовʼязані реалізувати всі нащадки».

ABC (abstract base class — абстрактний базовий клас) — це клас, який не призначений для створення обʼєктів; він лише описує, що мають уміти нащадки. Позначений @abstractmethod метод перетворює клас на незавершений: створити обʼєкт такого класу Python не дасть, доки метод не реалізовано.

Головна цінність abc — не «строгість» заради строгості, а перенесення помилки ближче до причини. Це та сама ідея, що й у темі 19: чим раніше зловлено, тим дешевше виправити.

Брати abc варто, коли базовий клас справді описує контракт для кількох незалежних реалізацій — наприклад, наші носії Папір, Аудіо, Файл усі мусять уміти як_видати(). Для пари класів, які пише одна людина в одному файлі, це зайва церемонія.

11 / ЦінаЦіна наслідування

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

Це найсильніший вид звʼязності, який є в мові. Похідний клас залежить не від опублікованого інтерфейсу базового, а від його внутрішнього устрою: які атрибути той заводить, які методи кличе всередині себе, у якому порядку. Автор базового класу міняє приватну деталь — і ламає нащадків, яких він ніколи не бачив. Це явище має власну назву: проблема крихкого базового класу.

Глибина не додається, а множиться. Щоб зрозуміти метод у класі на пʼятому рівні ієрархії, треба тримати в голові пʼять класів одночасно й памʼятати, який із них щось перевизначив. Читання коду перетворюється на стрибки вгору-вниз по файлах. Робочий орієнтир простий: два рівні — нормально, три — привід задуматись, чотири й більше — майже завжди помилка проєктування.

Ієрархію дуже важко переробити. Композицію можна переставити майже безкарно: замінив один обʼєкт у полі — і все. Ієрархія ж зашита в заголовки класів, і будь-яка її зміна зачіпає всі методи, що кличуть super(), усі перевірки isinstance і весь код, що покладався на порядок MRO.

І наслідування «навпаки» — теж помилка. Спокуса успадкувати клас лише заради того, щоб дістатися його готових методів (успадкувати list, щоб мати append), закінчується погано: разом із потрібним методом нащадок отримує весь інтерфейс базового класу, включно з тим, що для нього безглуздо. Твоє Замовлення(list) раптом можна відсортувати, порізати зрізом і помножити на три. Правильний хід — покласти список у поле.

12 / ПідсумокЩо забрати з теми

Наслідування й композиція розвʼязують одну задачу — не писати те саме двічі — але платять за це різну ціну.

• Похідний клас отримує методи базового, а не копію його даних. Атрибути зʼявляються в обʼєкті тоді, коли якийсь __init__ їх запише.
• Метод шукається по __mro__ зліва направо й береться перший знайдений — точно так само, як імʼя шукається по LEGB. Не знайшли ніде — AttributeError.
• Перевизначення без super() замінює поведінку, з super() — розширює. Забутий super().__init__(...) — класична пастка: обʼєкт створюється, а падає значно пізніше й в іншому місці.
• super() — це «наступний у MRO», а не «мій батько». Тому він не дублює імені базового класу, сам підставляє self і в ромбі заходить у кожен клас рівно один раз, тоді як прямі виклики Батько.метод(self) виконують спільного предка двічі.
• Композиція — «має всередині»: обʼєкт лежить у полі, а робота делегується йому. Вона не множить класи на кожній новій вимозі й дозволяє змінити поведінку під час роботи програми, а не тільки під час написання коду.
• Питай про вміння, а не про рід. Прямий виклик методу приймає все, що вміє потрібне; isinstance лишай для випадків, коли важливий саме тип. abc потрібен, щоб забутий метод спливав при створенні обʼєкта, а не посеред роботи.

Далі — тема 27, магічні методи. Ми вже двічі стикалися з __init__ і жодного разу не спитали, чому в нього такі дивні підкреслення. Там зʼясується, що len(x), x + y, x == y і навіть print(x) — це виклики методів із такими самими іменами, і що написати свій клас, який поводиться як вбудований тип, — питання пʼяти рядків. А тема 28 покаже, як dataclass прибирає з наших класів увесь одноманітний __init__ разом узятий.