Чим спадкування відрізняється від підтипу?

Що стосується мови програмування, що означає підтип? Я чув, що "Спадщина не є субтипізацією". Тоді в чому полягають відмінності між успадкуванням та підтипом?

[Я не надто замислювався над проблемами об'єктно-орієнтованих типів систем, але скажу те, що знаю, щоб розпочати дискусію.]

$A$$B$$A$$B$$A$$B$

$A$$B$

Структурне підтипування не забезпечує поведінкове підтипування, оскільки структура типу може збігатися з випадкових причин. Однак визначити очікувану поведінку непросто. Так, у багатьох мовах програмування використовується проміжна точка, де користувач повинен оголосити, який тип є підтипом якого. Це називається "номінальним підтипом" . Дивіться запитання про Імпліцит проти явного підтипудля обговорення цього питання. Ідея полягає в тому, що програміст повинен забезпечити поведінкове підтипування для всіх заявлених підтипів, використовуючи власну винахідливість. Мова не може запропонувати жодної допомоги. Однак усі заявлені підтипи повинні бути принаймні структурними підтипами. В іншому випадку програма не зможе набрати перевірку. Мова може допомогти забезпечити це. (Деякі мови програмування не мають достатньо хороших типів систем, щоб забезпечити це під час компіляції. Якщо так, помилка типу буде виявлена ​​під час виконання, або, можливо, можуть виникнути помилкові результати. Такі отвори типу, очевидно, небажані.)

Коли ви визначаєте підкласи в об'єктно-орієнтованих програмах, зазвичай додаються загальнодоступні поля (або методи). У більшості мов програмування такі підкласи розглядаються як номінальні підтипи. Питання в тому, чи є вони також структурними підтипами. Якщо їх немає, тобто мова програмування дозволяє оголошувати номінальні підтипи, які не є структурними підтипами, то в мові програмування будуть отвори типу.

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

Однак якщо в надкласі або підкласі є методи, які беруть аргументи того ж типу, що й сам, або повертають результати того ж типу, що і сам, тоді виникають проблеми. Тоді тип інтерфейсу підкласу не є структурним підтипом класу надкласу. Широко використовувані безпечні для мови мови програмування, такі як Java, не дозволяють використовувати такі підкласи. Отже, вони обмежують мову, щоб отримати безпеку типу. Кажуть, що мова програмування Ейфеля принесла в жертву безпеку типу, щоб натомість отримати гнучкість . Якщо розробляти систему сильного типу, яка зберігає гнучкість, слід відмовитися від принципу, що підкласи породжують підтипи. Звідси заголовок статті "Спадщина не підписувати". Автори пропонують інше поняття підтипу вищого порядку, яке працює замість цього. У Кіма Брюса також є тісно пов'язана пропозиція під назвою "відповідність", яка досягає того ж ефекту. Дивіться цю презентацію . Також корисним є позиційний документ Ендрю Блек.

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