1)
иерархия типов определяется законами логики из заданных аксиом,
то есть, дана Богом и не может быть изменена.
2)
иерархия классов определятся произволом программиста,
и может быть перекручена, чуть ли не в произвольном порядке.
3)
соответствие иерархий выполняется тогда, когда
для каждой пары подкласс - надкласс спецификация подкласса
является подтипом спецификации надкласса.
4)
проверка типов в компиляторе гарантирует работу программы
только тогда, когда иерархия типов соответствует иерархии классов.
5)
принципы дизайна по контракту создают иерархии классов
соответствующие иерархиями типов.
точка.

SiemarglthingizВозьмем в $UReal$ значение $w$, причем $w != h$, после этого, используя
аксиому $gw\_sw$, из любого $f$, у которого ширина была задана
равной $w$, то есть, равного $SetWidth(f1, w)$ извлечем это $w$
h = GetWidth(f) = GetWidth(SetWidth(f1, w)) = w
Противоречие. Это означает, что две различные версии аксиом $gw\_sh$ не могут
выполняться вместе.
Отсюда следует, что нет никакой возможности в принципе считать $Square$ подтипом $Rectangle$.
Так же как нельзя считать $Rectangle$ подтипом $Square$.

Мне кажется, уважаемый Чингиз, что ты таки ошибаешься в двух местах:
1. Выделено красным. Из одной неверной предпосылки не следует ложность другой.

это не посылки, это следствия из аксиом. Из одной аксиомы строится один класс,
из другой - второй. аксиомы не совместимы и равнозначны. Классы в этом смысле
одинаковы - значение переменной одного класса не может быть присвоено в переменную
другого и наоборот.

Siemargl
Что считать подтипом? Похоже, что производный класс всегда является подтипом.

И тогда нужно аккуратно совместить LSP, где утверждение про подтипы и - контракты, где про производные классы.
тип - это спецификация, то есть, список аксиом.
подтип - более длинный список аксиом, содержащий родительский список.

Принцип подстановки Лисков меня уже не волнует, у меня свой критерий, лучше есть.
http://www.sql.ru/forum/actualthread.aspx?tid=800476&pg=10#9707022

аналогичный трехлетний окружностесрач на dxdy.ru

Эллипс и окружность: что от чего наследуется.

http://dxdy.ru/topic49360.html


Цитаты из Страуструпа и Дейта перепостил для надежности хранения
Joker_vDТак, прошу прощения. Страуструп придерживается несколько другой точки зрения:

For example, in Section 23.4.3.1 of his book The C++ Programming Language, 3rd edition (Addison-Wesley, 1997), page 703, Bjarne Stroustrup​ has this to say:

"For example, in mathematics a circle is a kind of an ellipse, but in most programs a circle should not be derived from an ellipse or an ellipse derived from a circle. The often-heard arguments “because that’s the way it is in mathematics” and “because the representation of a circle is a subset of that of an ellipse” are not conclusive and most often wrong. This is because for most programs, the key property of a circle is that it has a center and a fixed distance to its perimeter. All behavior of a circle (all operations) must maintain this property (invariant). On the other hand, an ellipse is characterized by two focal points that in many programs can be changed independently of each other. If those focal points coincide, the ellipse looks like a circle, but it is not a circle because its operations do not preserve the circle invariant. In most systems, this difference will be reflected by having a circle and an ellipse provide sets of operations that are not subsets of each other."

Он не одинок, есть полно статей, где проводится та же идея, что "окружность — не эллипс, квадрат — не прямоугольник". Например:

K. Baclawski, B. Indurkhya, “The Notion of Inheritance in Object-Oriented Programming” (CACM 37, No. 9, September 1994​)
J. Rumbaugh, “A Matter of Intent: How to Define Subclasses” (Journal of Object-Oriented Programming, September 1996)
R.C. Martin, “The Liskov Substitution Principle” (C++ Report, March 1996)


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



Joker_vD
Цитируя Дейта, "По моему мнению, любая модель наследования, в которой тип ОКРУЖНОСТЬ не является подтипом типа ЭЛЛИПС, вряд ли может считаться хорошей моделью действительности". И позже: "However, the fact remains that circles are ellipses in reality; if we choose not to regard them in that way in “our system,” then certainly the things that “our system” calls circles and ellipses differ in some rather important ways from circles and ellipses in the real world. Indeed, they simply aren’t circles and ellipses (by definition), at least as those constructs are conventionally defined and understood. [...] Note too that if “our system” includes “ellipses” that aren’t ellipses or “circles” that aren’t circles, then “our system” is likely to be seriously misunderstood, and possibly misapplied, both by our intended users and by people who might subsequently have to perform maintenance on the system. So if you really want to have a system that supports ellipse-like things that aren’t ellipses or circle-like things that aren’t circles, then I would suggest very strongly that—at the very least—you call those things something other than ellipses and circles."

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

У Дейта в "Date on Database: Writings 2000-2006" есть статья про модель наследования, так там он когда разбирает статью Лисков, все время сокрушается, что "объект" у нее означает и текущее значение переменной, и саму переменную, что так и не указаны отличия между "классом" и "типом" — или не сказано, что это синонимы, и т.п.

Тут у меня единодушное мнение со Страуструпом - я тоже пытался говорить, что
класс RSquare не имеет ничего общего с квадратами из математики, поэтому аппеляция к
геометрическому смыслу бессмысленна.
Далее, Страуструп говорит о проектировании, что если надо спроектировать классы.
Я пытался решить чисто технический вопрос уже есть класс Rectangle и класс Square из статьи Мартина (и именно такие как у Мартина и никакие другие) и для них написано пять триллионов шесть миллиардов пятсот тридцать одна программа.
Что будет если наследовать один из другого?
Наследовать можно, но поскольку один из классов не является подтипом другого,
теряется проверка типов. Вместо переменной родителя можно подставить переменную ребенка - компилятор пропустит, а на шаге выполнения задача сбойнет.
--

заодно определения


типизация - это свойство-средства языка, гарантирующее успешное вычисление корректного выражения.

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

Таким образом получаем, что с++ не вполне полиморфен.

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

tchingiz
заодно определения


типизация - это свойство-средства языка, гарантирующее успешное вычисление корректного выражения.

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

Таким образом получаем, что с++ не вполне полиморфен.

последнее улучшение. ))

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

из работы

отдельное спасибо Максиму Талдыкину

когда я говорю специальный, я так и пишу специальный полиморфизм.

частные случаи полиморфизма должны удовлетворять определению общего случая.
Как и частные случаи любого понятия должны удовлетворять определению общего случая того же понятия.
Например, квадрат частный случай прямоугольника, и квадрат удовлетворяет определению прямоугольника.