Есть ли конкретное название для парадокса «Квадрат наследует от прямоугольника»?

Определенная ошибка ООП показана с классом Square, унаследованным от Rectangle, где логически Square является специализацией Rectangle и поэтому должен наследовать от него, но все рушится, когда вы пытаетесь изменить длину или ширину Square.

Есть ли конкретный термин для описания того, что происходит с этим случаем?

object-oriented inheritance liskov-substitution

— Виктор
источник

Не могли бы вы объяснить, что именно "идет не так"? Я не понимаю, что вы имеете в виду

— комнат

Предполагая, что у прямоугольника есть виртуальный метод, который позволяет устанавливать размер, передавая длину и ширину, установка другой длины и ширины в квадрате может вернуть прямоугольник, а установка такой же длины и ширины в прямоугольнике может вернуть квадрат. Любой код, которому нужно явно знать квадрат, может попытаться привести к квадрату. Я не вижу, как происходит сбой ...

Это не парадокс. Это случай неправильного моделирования проблемной области. Иерархия наследования НЕ обязательно согласуется с иерархией вещей в проблемной области. Приятно, когда это происходит, но хитрость в хорошей модели состоит в том, чтобы понять, где нужно делать вещи иначе, чем в реальном мире.

— Майкл Кохне

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

— Маке

@GrandmasterB Я говорю о «любом человеке, вещи или ситуации, имеющей явно противоречивый характер». Противоречие состоит в том, что, если у квадрата есть различные свойства, мы должны сказать, что «Квадрат не является своего рода Прямоугольником», когда мы ожидаем, что Квадрат будет подтипом Прямоугольника. Вероятно, ни у одного реального приложения не было бы типов Rectangle и Square, это просто абстракция, иллюстрирующая проблему определенного типа, которая может появиться в парадигмах на основе классов.

— Виктор

Ответы:

Википедия просто называет это проблемой кругового эллипса

Проблема кругового эллипса в разработке программного обеспечения (иногда известная как проблема прямоугольника ) иллюстрирует ряд подводных камней, которые могут возникнуть при использовании полиморфизма подтипа в моделировании объектов. Проблемы чаще всего встречаются при использовании объектно-ориентированного программирования.

Это L в акрониме SOLID, который известен как принцип подстановки Лискова . Эта проблема возникает как нарушение этого принципа.

Проблема заключается в том, какие отношения подтипов или наследования должны существовать между классами, которые представляют круги и эллипсы (или, аналогично, квадраты и прямоугольники). В более общем плане проблема иллюстрирует трудности, которые могут возникнуть, когда базовый класс содержит методы, которые видоизменяют объект таким способом, который может сделать недействительным (более сильный) инвариант, найденный в производном классе, что приводит к нарушению принципа подстановки Лискова ...

— Марк Канлас
источник

И, читая его, Википедия упоминает более академическое объяснение как «[нарушение] принципа замены Лискова». Спасибо :)

— Виктор

Ну, это только нарушение в зависимости от того, как вы на это смотрите. Лично все круги являются эллипсами; Нарушения нет. Начинается нарушение, если методы для эллипса становятся ограничительными. Тогда в этом конкретном сценарии круг не может быть подтипом этого конкретного контракта эллипса.

— Марк Канлас

@MarkCanlas Проблема состоит в бесспорном нарушении принципа замещения Лиск. Это не может быть нарушением других принципов, но никто этого не утверждал. Если проблема не возникает из-за того, что контракты не содержат инварианта, который может быть нарушен (хотя я не могу представить себе полезную модель, где это так), нарушение LSP может и не быть, но это не означает, что проблема , когда это происходит, не из-за нарушения LSP.

@Mark Canlas: Нет, постоянный круг - это постоянный эллипс, изменяемый круг - это не изменяемый эллипс. В геометрии предполагается постоянство, вы не можете изменить эллипс, вы можете взять другой эллипс

— maxim1000

Историческое ограничение / правило принципа подстановки Лискова гласит, что когда подтип добавляет новые методы, этим методам не разрешается манипулировать состоянием объекта таким образом, что он создает историю (то есть ряд состояний), которая не является разрешено в супертипе. Например, вы не можете сделать подтип неизменяемого изменяемого, потому что, когда манипулируют только с помощью методов супертипа, состояние всегда одинаково, тогда как при манипулировании с помощью методов мутатора подтипа, состояние действительно изменяется. Это история, которая не допускается супертипом.

— Йорг Миттаг

Я бы посчитал это нарушением принципа подстановки Лискова - Squareподкласс специально нарушает инвариант, что длина и ширина независимы.

— Пол Филлипс
источник

На более фундаментальном уровне, чем принцип подстановки Лискова, это ошибка категории или ошибка категории

В контексте моделирования поведения квадрат просто не является типом прямоугольника.

Когда вы понимаете это, проблема испаряется, так как исходное предположение (квадрат является типом прямоугольника) удаляется из игры.

Проблема с этим ответом состоит в том, что начиная со школьной скамьи каждый, кто занимается геометрией, считает, что квадрат - это тип прямоугольника. Но очень важно понимать, что это верно только в очень специфическом контексте (классификация геометрических фигур на основе свойств их внутренних углов). С точки зрения поведения квадрат не является прямоугольником. Рассматривать один набор классификации в неправильном контексте - ошибка категории.

— Кормак Мулхолл
источник