Ответ на »сообщение 974« (AVC)
___________________________
>>>Хотелось бы услышать по этому поводу критику, суровую и полную скептицизма. :)
Нет проблем :)
Это напоминает формальный синтез алгоритмов по пред- и постусловиям, предложенный Дейкстрой в книге "Дисциплина программирования" и подробно описанный Грисом в учебнике "Наука программирования".
Я читал Гриса запоем: еще бы, он показывал, как превратить программирование в точную науку. Наконец я добрался до главы с многообещающим названием "Пример сложной программы" и прочел, как формально построить алгоритм Евклида для нахождения НОД. И далее шли рассуждения о том, что для задач реальной сложности формальное построение алгоритмов невозможно и программист должен интуитивно выделять несложные базовые алгоритмы, для которых имеет смысл предложенный подход.
Теперь, когда в качестве примера приводится формальное описание стека, меня это убеждает очень слабо. Мейер всего навсего показал, что "в некоторых простейших случаях симантику некоторых абстрактных объектов можно описать формально".
Пример не является доказательством.

Ответ на »сообщение 961« (Денис Зайцев)
___________________________
>>>В частности, имеется довольно известный парадокс ОО-проектирования "Круг - это не эллипс".
Все приведенные рассуждения о "правильном" подходе гроша ломанного не стоят без указания класса решаемых задач.
Если мы собираемся предъявлять человеку квадраты, треугольники, круги и эллипсы с целью определения скорости реакции, то круг и эллипс должны быть наследниками общего прототипа, наравне с квадратом и треугольником.
Можно предложить задачи для которых удобнее унаследовать круг от эллипса и эллипс от круга.
Иерархию наследования МОЖНО строить от общего к частному, как в теории множеств (только это я и утверждал), а можно от простого к сложному.

Ответ на »сообщение 966« (Варяжский Гость)
___________________________


Сказать можно, а гарантировать - вряд ли.
<...>
Вводя новыми интерфейсами новые слои абстракции мы за видимую свободу безболезненного манипулирования платим потерей контроля над реализацией.


Предмет обсуждения предстал с неожиданной стороны.
Мне кажется, Вашу точку зрения, а также точку зрения Ильи Ермакова (см. »сообщение 945«) вполне можно обозначить как скептическую.
В соответствии с ней, невозможно задать полноценную формальную спецификацию (интерфейс).
Математика бессильна, остается уповать на мудрость естественного языка.
Где-то это недалеко от того удивления, которое побудило меня задать вопрос об АТД.

Но давайте теперь испытаем этот скептицизм на прочность.
Рассмотрим упомянутый мейеровский пример АТД для стека.
Кроме всего прочего, Мейер определяет для стека 4 аксиомы:

A1. item(put(s,x)) = x
A2. remove(put(s,x)) = s
A3. empty(new)
A4. not empty(put(s,x))

где s -- стек, а x -- его элемент.
В следующем разделе (с красивым заголовком "Ничего кроме правды" :) ) он старается показать, что этих аксиом достаточно, чтобы описать семантику стека.
Создается впечатление, что ему удалось-таки задать семантику АТД, не прибегая при этом к реализации.
Хотелось бы услышать по этому поводу критику, суровую и полную скептицизма. :)

Имеем описание последовательности вызова методов, осуществляемых модулем. Короче алгоритм имеем. Почему нельзя сказать реализует ли другой модуль этот алгоритм, или нет?
В интерфейсе.Сказать можно, а гарантировать - вряд ли.
Хочется поблагодарить за внимание, Вами оказанное.
Абстрагированию подвергается внутренняя структура механизма реализации. В интерфейсе описываются условия, которым должен удовлетворять алгоритм. Гарантии соблюдения этих условий надо требовать у создателя модуля, а не у интерфейса.
Когда Вы говорили о формальном синтезе Вы принудительный интерфейс имели в виду?

Рассуждения о кругах и эллипсах напомнили мне о садистском эксперименте в лаборатории Павлова.
У собаки выработали положительный слюноотделительный рефлекс на эллипс и отрицательный -- на круг.
Затем стали поворачивать табличку с рисунком круга, так что круг "превращался" в эллипс и обратно.
Бедное животное чуть не сдохло от возмущения. :)

Но есть в мире справедливость -- теперь наша очередь...

Ответ на »сообщение 970« (Trurl)
___________________________


Рассуждая в том же духе:
С точки зрения теории множеств не подлежит никакому сомнению, число 2 и число  3 - это два разных объекта. А с точки зрения ООП, если мы взяли число 2 и изменили его значение на 3 - это тот же самый объект.

Наверное, все-таки, взяли переменную, а не само число 2. :)

Ответ на »сообщение 967« (Денис Зайцев)
___________________________
С точки зрения теории множеств не подлежит никакому сомнению, что эллипс с полуосями (1, 2) и эллипс с полуосями (2, 3) - это два разных объекта. А с точки зрения ООП, позволяющего объекту менять свои свойства (почему бы и нет? никаких принципов ООП это не нарушает!), если мы взяли эллипс (1, 2) и изменили его полуоси на (2, 3) - это, безусловно, тот же самый объект! Мы просто изменили его свойства.

Рассуждая в том же духе:
С точки зрения теории множеств не подлежит никакому сомнению, число 2 и число  3 - это два разных объекта. А с точки зрения ООП, если мы взяли число 2 и изменили его значение на 3 - это тот же самый объект.

Ответ на »сообщение 967« (Денис Зайцев)
___________________________
Да, Вы абсолютно правы в своем замечании о том, что здесь логично указывать размеры фигуры именно при создании.
Чтобы показать, что никакого парадокса нет вообще, расширим немного задачку - нам требуется работать со всеми кривыми второго порядка. Для них можно задать общий тип, который будет содержать максимум параметров. И тут опять можно надумать себе "парадоксы", что от чего наследовать... Но зато теперь уже ясно понимаем, что наследовать кривую второго порядка от круга - глупее не придумаешь...

Собственно, модель, основанная на теории множеств - это реляционная модель. Существование всяких O/R-mapper'ов, ни один из которых не является де-факто стандартом; существование множества объектных (не реляционных) СУБД - всё это косвенно указывает на то, что логическая модель ООП и логическая модель, основанная на теории множеств (реляционная), не изоморфны друг другу.

Ответ на »сообщение 962« (Илья Ермаков)
Но можно и ввести, явным образом гарантируя для кругов инвариант "r1=r2". А вот введение двух несвязанных типов "эллипс" и "круг" является бессмыссленным решением
В английских ссылках, которые я привёл, более подробно разбирается этот пример. Особенно в этой:
http://www.parashift.com/c++-faq-lite/proper-inheritance.html
(там нужно перейти на вопрос [21.6], с него начинается очень подробное обсуждение).
Автор этого FAQ утверждает, что если мы документировали поведение объекта базового класса (например, гарантировали, что функция SetSize устанавливает полуоси эллипса и точка; никаких исключений в базовом классе не предусмотрено!), то не имеем права ни на йоту выходить за пределы этого поведения в любом порождённом классе. Это принцип ОО проектирования, которым автор не может поступиться. И многие с ним согласны. Хотя многие - нет. Так вот, если принять этот принцип, то мы не имеем права в порождённом классе "Круг" "нарушать контракт" (по выражению автора), который мы подписали в классе "Эллипс" и который обязывает любой эллипс иметь возможность независимого изменения полуосей.

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

С точки зрения теории множеств не подлежит никакому сомнению, что эллипс с полуосями (1, 2) и эллипс с полуосями (2, 3) - это два разных объекта. А с точки зрения ООП, позволяющего объекту менять свои свойства (почему бы и нет? никаких принципов ООП это не нарушает!), если мы взяли эллипс (1, 2) и изменили его полуоси на (2, 3) - это, безусловно, тот же самый объект! Мы просто изменили его свойства. Налицо несовпадение понятий в теории множеств и в ООП. А вот если мы запрещаем объекту изменять свои свойства после создания - это уже сближает нашу модель с моделью теории множеств. Надо, правда, ещё обеспечить, чтобы два объекта с одинаковыми свойствами считались одинаковыми (например, проверка того, что данный список содержит данный объект, должна проверять содержимое объектов, а не адреса памяти, по которым они расположены). Вот тогда соответствие между нашей ОО-моделью и моделью теории множеств будет полным. Тут, правда, встаёт вопрос - будет ли такая модель удобной с точки зрения программирования.