Чи існує конкретна назва парадоксу «Квадратний спадок від прямокутника»?

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

Чи є конкретний термін для опису того, що йде в цьому випадку не так?

object-oriented inheritance liskov-substitution

— Віктор
джерело

Ви можете, будь ласка, пояснити, що саме "йде не так"? Я не розумію, що ти маєш на увазі

— гнат

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

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

— Майкл Коне

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

— Макке

@GrandmasterB Я проходжу "будь-яку людину, річ або ситуацію, що має суперечливий характер". Суперечність полягає в тому, що якщо квадрат має різні властивості, ми мусимо сказати, що «Квадрат - це не такий собі прямокутник», коли насправді ми очікуємо, що Квадрат буде підтипом прямокутника. Напевно, жодне реальне застосування не матиме типів Прямокутник і Квадрат, це лише абстракція, щоб проілюструвати певний вид проблеми, яка може з’явитися в парадигмах на основі класу.

— Віктор

Відповіді:

Вікіпедія лише називає це проблемою кола-еліпса

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

Це L у абревіатурі SOLID, який відомий як принцип заміни Ліскова . Ця проблема виникає як порушення цього принципу.

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

— Марк Канлас
джерело

І, читаючи це, Вікіпедія згадує більш академічне пояснення як "[порушення] принципу заміни Ліскова". Дякую :)

— Віктор

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

— Марк Канлас

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

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

— maxim1000

Обмеження історії / правило принципу заміни Ліскова говорить, що коли підтип додає нові методи, цим методам не дозволяється маніпулювати станом об'єкта таким чином, що він створює історію (тобто серію станів), яка не є дозволено в супертипі. Наприклад, ви не можете зробити підтип незмінного мутабельного, тому що, коли маніпулюють лише методами супертипу, стан завжди однаковий, тоді як при маніпулюванні мутаторними методами підтипу стан змінюється. Це історія, яку заборонено супертипом.

— Йорг W Міттаг

Я вважав би це порушенням принципу заміни Ліскова - Squareпідклас конкретно порушує інваріант, що довжина і ширина не залежать.

— Пол Філіпс
джерело

На більш фундаментальному рівні, ніж Принцип заміщення Ліскова, це помилка категорії або помилка категорії

У контексті моделювання поведінки квадрат просто не є типом прямокутника.

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

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

— Кормак Малхолл
джерело