Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 [9] 10   вперед  Ctrl      все
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
тут люди прямо жить не могут без виртуальных функций
и позднего связывания - динамическая диспетчеризация

К сообщению приложен файл. Размер - 0Kb
28 окт 10, 01:57    [9689339]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
tchingiz
_мод
ZyK_BotaN
как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.

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

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

дивное единодушие во мнении с классиками

К сообщению приложен файл. Размер - 0Kb
28 окт 10, 02:04    [9689350]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
subsumption -- это правило категоризации, ребенок отнесен к категории (типу) родителя.
28 окт 10, 02:07    [9689353]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
tchingiz
ZyK_BotaN
tchingiz
ZyK_BotaN

тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.

с потерей точности - да.
поэтому в жизни вещественные - целые ( целые - натуральне) есть,
а по принципу Лисков их нельзя преобразовать. Они - разные типы.


автор
Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

где здесь про перобразование типов от родительского к дочернему?

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

глава type information, lost and found в теории объектов Карделли целиком посвящена
сохранению всех атрибутов ребенка.
Послкольку они сохраняются, сохраняется возможность обратного преобразования.
28 окт 10, 02:24    [9689375]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6067
ZyK_BotaN
в джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.
В Java все объекты - ссылки.

tchingiz
глава type information, lost and found в теории объектов Карделли целиком посвящена
сохранению всех атрибутов ребенка.
Послкольку они сохраняются, сохраняется возможность обратного преобразования.

В языках, где объекты только в динамической памяти - Java, .NET, D, Delphi проблем потери атрибутов нет. Преобразовывай куда хочешь.
28 окт 10, 09:09    [9689705]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
если рассматривать нормальное наследование, а не эти идиотские примеры,
как у нас, то будет понятно, что при наследовании в подкласс добавляются
поля. Это увеличение на одну размерность кортежа.
При преобразовании ребенка в родителя - это поле надо отбросить.
Тогда об обратном преобразовании можно не мечтать, информация утеряна.

Фокус в том, что никаких (неявных) преобразований типов не д.б. вообще. А вся проблема в ЯП с жесткой типизацией.
float a
int b
b=1   - тип b - int
a=b   - тип a - float что неверно, а д.б. int
Т.е. переменная должна изменять свой тип в соотв. с присвоенным ей выражением. В динамически типизированных ЯП это всегда так. Вот тогда и будет нормальное наследование и истинный полиморфизм. Ф-ия ident(x) -> x возвращает x с сохранением его типа. И тогда методы родителя непосредственно применяются к ребенку, подстраиваясь под его тип. Вот тогда и принцип Лисков заработает.
28 окт 10, 09:49    [9689948]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ZyK_BotaN
у меня вся фишка в иммутабельности

Чисто функциональное программирование действительно снимает все проблемы. Вот только оно никак не согласуется с парадигмой БД, в которой как раз и хранятся изменяющиеся объекты, причем очень разных типов.
28 окт 10, 09:55    [9689993]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 104078
Siemargl
ZyK_BotaN
в джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.
В Java все объекты - ссылки.


я то в курсе. только ты не сможешь подменить объект. ведь нет операции взятия адреса.
ты можешь работать с объектом только через публичные методы.

а в с++, зная адрес объекта, можно его подменить.
28 окт 10, 12:56    [9691872]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 104078
Siemargl

Послкольку они сохраняются, сохраняется возможность обратного преобразования.

В языках, где объекты только в динамической памяти - Java, .NET, D, Delphi проблем потери атрибутов нет. Преобразовывай куда хочешь.[/quot]

на счет Delphi уверен?
а то я когда-то писал на нем, и вроде на стеке объекты создавал. хотя точно не помню.
28 окт 10, 12:57    [9691891]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 104078
_мод
ZyK_BotaN
у меня вся фишка в иммутабельности

Чисто функциональное программирование действительно снимает все проблемы. Вот только оно никак не согласуется с парадигмой БД, в которой как раз и хранятся изменяющиеся объекты, причем очень разных типов.

согласен.
28 окт 10, 12:58    [9691899]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
--------------------------------
Guest
_мод
ZyK_BotaN
у меня вся фишка в иммутабельности

Чисто функциональное программирование действительно снимает все проблемы. Вот только оно никак не согласуется с парадигмой БД, в которой как раз и хранятся изменяющиеся объекты, причем очень разных типов.

С парадигмой тоже не все очевидно.
Создания битемпоральных баз данных - это практически использование иммутабельных объектов.
28 окт 10, 16:06    [9694240]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
--------------------------------
С парадигмой тоже не все очевидно.
Создания битемпоральных баз данных - это практически использование иммутабельных объектов.

Сложно представить работу такой БД в многопользовательской среде
28 окт 10, 16:31    [9694589]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
--------------------------------
Guest
_мод

Сложно представить работу такой БД в многопользовательской среде

А что не так в многопользовательской?
Чем хуже, чем в однопользовательской?
Или ты имел в виду - когда идет много обновлений?
28 окт 10, 16:42    [9694715]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 104078
_мод
--------------------------------
С парадигмой тоже не все очевидно.
Создания битемпоральных баз данных - это практически использование иммутабельных объектов.

Сложно представить работу такой БД в многопользовательской среде


Erlang:
http://ru.wikipedia.org/wiki/CouchDB
http://ru.wikipedia.org/wiki/Mnesia

K:
http://kx.com/
28 окт 10, 22:19    [9696581]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
Siemargl
tchingiz, понял про ЗПТ, типа спс за доверие.

Топик скатывается. Предлагаю изобрести более наглядный пример, чем квадратики и поля чисел.

ZyK_BotaN, пример слишком тривиален (и дажи при том ты ромб выбросил, как неудобный=) и неопределены аксиомы, чтобы на нем тренировать.

для классического примера Мартина я их записал.
30 окт 10, 03:36    [9704747]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
_мод
ZyK_BotaN
как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.

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

во первых, S подкласс, T надкласс.
во вторых, не ругаются.
Из подкласса в надкласс присваивать можно. Это не ошибка.
Это такое поведение компиляторов было заложено в них и постулировалось.
А потом начались сомнения и Лисков придумала принцип.
30 окт 10, 03:39    [9704751]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
Siemargl
ZyK_BotaN
в джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.
В Java все объекты - ссылки.

tchingiz
глава type information, lost and found в теории объектов Карделли целиком посвящена
сохранению всех атрибутов ребенка.
Послкольку они сохраняются, сохраняется возможность обратного преобразования.

В языках, где объекты только в динамической памяти - Java, .NET, D, Delphi проблем потери атрибутов нет. Преобразовывай куда хочешь.

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

К сообщению приложен файл. Размер - 0Kb
30 окт 10, 03:58    [9704759]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
parameter passing and assignment copy references, not the associated attribute records.
30 окт 10, 04:02    [9704760]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
tchingiz
_мод
ZyK_BotaN
как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.

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

во первых, S подкласс, T надкласс.
во вторых, не ругаются.
Из подкласса в надкласс присваивать можно. Это не ошибка.

так уже для порядку


http://www.intuit.ru/department/se/oopbases/14/2.html


Предположим, что для структуры наследования на рисунке вверху объявлены следующие сущности:

p: POLYGON; r: RECTANGLE; t: TRIANGLE


Тогда допустимы следующие присваивания:
p := r
p := t


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


30 окт 10, 04:36    [9704770]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31974
ZyK_BotaN
egorych
назови его makeRectangle() и вопросы уйдут. Если я работаю с только с квадратами, на кой хрен мне сдался прямоугольник??? и да, я понимаю, что код не скомпилится, и я буду долго ломать голову, почему, потом, наконец, залезу с исходник твоего класса, если он у меня есть, или напишу тучу unit-тестов, чтобы выяснить, как работает твой класс.


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

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

то есть, мое предложение о восстановлении является условием тогда и только тогда когда
выполняется инвариант типа.
Пока явного указания не нашел. Зато нашел в Бертране Мейере (автор программирования по контракту) вот такой текст



http://www.intuit.ru/department/se/oopbases/14/9.html
Предположим теперь, что к объекту типа B, достижимому через сущность типа A, применяется статическое связывание. При этом из-за того, что соответствующая версия процедуры rA , как правило, не будет поддерживать необходимый инвариант (как, например, depositACCOUNT1 для объектов типа ACCOUNT2 или displayWINDOW для объектов типа BUTTON), будет получаться неверный объект (например, объект класса ACCOUNT2 с неправильным полем balance или объект класса BUTTON, неправильно показанный на экране).

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


здесь В - ребенок, А - родитель, статическое связывание - ранне связывание == вызов метода родителя
30 окт 10, 05:25    [9704796]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4742
tchingiz, вот да, именно это я и пытался донести нашему общему другу ZiK_BotaN.

PS используя его технику легко отнаследовать квадрат от круга, например.. Но это же абсурд
PSS tchigiz, красивенько получилось :-))
30 окт 10, 12:21    [9705048]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 104078
egorych

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


дай пример. мне тут обещали, используя мою технику, отнаследовать прямоугольник от квадрата, но я не увидел этого.

Моя техника базировалась на том, что квадрат всегда является прямоугольником, наоборот уже не верно.
а кругом квадрат не может являться в принципе.
30 окт 10, 17:37    [9705894]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 104078
tchingiz

1
на месте прямоугольника, квадрат не должен работать в точь-в-точь как прямоугольник.

может все же не обязан, но все же может?

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

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


больше на тему правильности моей иерархии пока спорить не будем, давай найдем ответ на следующую задачу на тему контрактного программирования:

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

моим решением, является иерархия представленная выше, но у нее есть огромный недостаток - неизменяемость данных. как решить ту же проблему для изменяемых объектов я не знаю.
30 окт 10, 17:50    [9705941]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ViPRos
Member

Откуда:
Сообщений: 9389
ZyK_Bota
Nа кругом квадрат не может являться в принципе.

а ты попобуй сжать квадрат в точку
30 окт 10, 18:22    [9706054]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 104078
ViPRos
ZyK_Bota
Nа кругом квадрат не может являться в принципе.

а ты попобуй сжать квадрат в точку


и как это мне поможет?
если на то пошло, то я могу точку от квадрата отнаследовать , но не квадрат от круга
30 окт 10, 18:36    [9706081]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 [9] 10   вперед  Ctrl      все
Все форумы / Программирование Ответить