|
|
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNtchingiz, мы выяснили, что квадрат не является подтипом прямоугольника. давай теперь решим задачку, как нам наилучшим образом реализовать контракт из задачки: ZyK_BotaN Есть класс прямоугольников, и есть подпрограммы, которые умеют работать только с прямоугольником у которого все стороны равны. Как нам обезопасить использование этих подпрограмм? моим решением, является иерархия представленная выше, но у нее есть огромный недостаток - неизменяемость данных. как решить ту же проблему для изменяемых объектов я не знаю. /topic/800476&pg=7#9681990 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2010, 01:50 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNegorych PS используя его технику легко отнаследовать квадрат от круга, например.. Но это же абсурд дай пример. мне тут обещали, используя мою технику, отнаследовать прямоугольник от квадрата, но я не увидел этого. Моя техника базировалась на том, что квадрат всегда является прямоугольником, наоборот уже не верно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2010, 01:55 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
во первых, почему в твоем коде функции showШото не засунуты в свой класс под именем show? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2010, 02:00 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Ну сколько раз по одному месту на стене.... Где аксиоматика классов? Нет аксиоматики - нет контрактов и нет программы. Контракт - это описаниие кто и что обязуется выполнить. ЗЫ. Сижу на горе с ноутбуком =) ЗЫ2. Мультик был советский - два чела смотрят с разных сторон на предмет: 1й - круг!!! 2й - квадрат!!! .... А предмет - цилиндр. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2010, 09:39 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingizво первых, почему в твоем коде функции showШото не засунуты в свой класс под именем show? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. в моем случае эти функции не принадлежат типу, а используют его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2010, 15:13 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
с восстановлением ребенка, который делает вид, что он родитель к ребенку мы уже разобрались? /topic/800476&pg=3#9674202 в исходном принципе действительно не заметно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2010, 23:34 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2010, 23:57 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
а, getSpace выводится из двух других, для нее не нужна специальная аксиоматизация Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 00:34 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Аксиоматика для Мартина Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Расширили аксиоматикой для ЗБотана Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 00:40 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 00:51 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
где отличия от Мартина? его первый пример, чуть переделанный под функциональный стиль. воид заменил на тип Код: plaintext 1. 2. 3. 4. 5. использование в фукнциональном стиле Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. вызов squareAfterF(Square(5)) выдаст false -- получился не Square, предполагаемый (но пока формально не введенный )инвариант нарушен. Чего добились? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 01:18 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
для фукнционального стиля без переменных) это требование авторВ цепочке должно быть два преобразования ребенок -> родитель, изменение ребенка, под видом родителя ранее написанными программами родитель -> ребенок выглядит так Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 01:26 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingiz, Это что за язык? Тяжеловато читается, в общем понятно, но надо бы синтаксис. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 16:54 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Introduction to RAISE Chris George March 2002 http://agp1.hx0.ru/arts/report249.pdf Алгебраическое проектирование класса http://www.softcraft.ru/design/classdesign/ авторКурс «Формальная спецификация и верификация программ» 2010-2011 уч.г. 2010 | 2009 | 2008 Лекторы: проф., доктор физ.-мат. наук Петренко А. К., канд. физ.-мат. наук Хорошилов А. В. Продолжительность: 36 часов лекции, 36 часов семинары, 72 часа самостоятельная работа. Аудитория: студенты 5 курса кафедр СП, АСВК и АЯ. Лекции по средам на первой паре (8:45 - 10:30) в аудитории П-8. http://sp.cmc.msu.ru/courses/fmsp/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2010, 18:45 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingiz, Нет, я не готов на такие жертвы - столько читать из чистой computer science ради квадратосрача ( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2010, 12:09 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Siemargltchingiz, Нет, я не готов на такие жертвы - столько читать из чистой computer science ради квадратосрача ( "квадрат/прямоугольник" - это только образец. а проблема такого рода встречается часто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2010, 13:00 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Siemargl, можно подумать, твой дизайн по контракту чемто отличается в смысле чистой сайенс от аксиом в рсл. наследование схемы там очевидное, иф зен элсе тоже очевиден. разве что обьявление типов, аксиомы и функциональный стиль не привычен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2010, 18:30 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
кстати, императивную часть и параметризацию схем в рсл не зачем читать для аксиом. ZyK_BotaN так мы с функциональным стилем покончили? или так написать наследование прямоугольников из квадратов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2010, 23:49 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingizкстати, императивную часть и параметризацию схем в рсл не зачем читать для аксиом. ZyK_BotaN так мы с функциональным стилем покончили? или так написать наследование прямоугольников из квадратов? покончили, и наследования не надо. меня интересует альтернативное решение(ф-му решению с наследованием), решение проблемы с выполнением контракта, что у прямоугольника, передаваемого в качестве параметра, все стороны равны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2010, 23:53 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingizкстати, императивную часть и параметризацию схем в рсл не зачем читать для аксиом. ZyK_BotaN так мы с функциональным стилем покончили? или так написать наследование прямоугольников из квадратов? Граждане а как это у вас квадрат наследовал прямоугольник. Сам по себе класс прямоугольника прекрасно выполняет функции квадрата. Наследование обычно идет в сторону расширения возможностей, тоесть прямоугольник может расширить квадрат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 00:33 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
обоже )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 00:59 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudio, Точно, я уже предлагал к солдатикам перейти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 08:26 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Siemarglrstudio, Точно, я уже предлагал к солдатикам перейти. ну зачем так сложно для чингиза. Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 11:48 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudio Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла какая ф-я принимающая целые числа не может принимать ноль? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 12:34 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNrstudio Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла какая ф-я принимающая целые числа не может принимать ноль? а какая ф-я принимающая прямоугольник не может принимать квадрат ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 14:15 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNкакая ф-я принимающая целые числа не может принимать ноль?деление? ;-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 15:23 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudioZyK_BotaNrstudio Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла какая ф-я принимающая целые числа не может принимать ноль? а какая ф-я принимающая прямоугольник не может принимать квадрат ? вот и я о том же. мой вопрос возник в связи с этой фразой : rstudioа потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла и "прямоугольник с квадратом" здесь не причем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 17:32 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudioZyK_BotaNrstudio Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла какая ф-я принимающая целые числа не может принимать ноль? а какая ф-я принимающая прямоугольник не может принимать квадрат ? для юмористов Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 18:25 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
egorychZyK_BotaNкакая ф-я принимающая целые числа не может принимать ноль?деление? ;-)) в случае целых все будет ок? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 18:38 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNв случае целых все будет ок?если в качестве делимого будет не ноль? - конечно. А что, есть сомнения в этом? )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 18:53 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingizrstudioZyK_BotaNrstudio Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла какая ф-я принимающая целые числа не может принимать ноль? а какая ф-я принимающая прямоугольник не может принимать квадрат ? для юмористов Код: plaintext 1. 2. 3. 4. 5. Опять у когото потеют ладошки пронаследовать квадрат от прямоугольника. Я же выше сказал что прямоугольник не может быть базовым классом для квадрата. Что же он делает в параметрах твоей функции ? Там должен торчать нормальный базовый класс. вот так вот другое дело Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 19:41 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Но вообще проблемы ООП прекрасно понимаю вот здесь я несколько раскрываю свое виденье проблем. Классы это нечто что должно "лепиться" к данным опираясь на свойства данных. Тоесть одна группа данных может мигрировать от одного класса к другому. В RS я это уже реализовываю. Мои классы это динамические группы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 19:47 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNtchingizкстати, императивную часть и параметризацию схем в рсл не зачем читать для аксиом. ZyK_BotaN так мы с функциональным стилем покончили? или так написать наследование прямоугольников из квадратов? покончили, и наследования не надо. меня интересует альтернативное решение(ф-му решению с наследованием), решение проблемы с выполнением контракта, что у прямоугольника, передаваемого в качестве параметра, все стороны равны. вот аксиоматика для обоих типов. http://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=-1#9543464 аксиома из версии Ректангле Код: plaintext 1. 2. 3. чтобы не задал в высоте, взятие ширины работает одинаково. аксиома из версии Сквере Код: plaintext 1. 2. Взять ширину вернет заданную высоту. эти две аксиомы не совместимы в принципе -- То есть, записав их вместе, получаем следующую аксиому: Код: plaintext 1. 2. 3. 4. Код: plaintext 1. Возьмем в $UReal$ значение $w$, причем $w != h$, после этого, используя аксиому $gw\_sw$, из любого $f$, у которого ширина была задана равной $w$, то есть, равного $SetWidth(f1, w)$ извлечем это $w$ Код: plaintext 1. выполняться вместе. Отсюда следует, что нет никакой возможности в принципе считать $Square$ подтипом $Rectangle$. Так же как нельзя считать $Rectangle$ подтипом $Square$. Можно считать их 'братьями', являющимися подтипом некоторого неполного, неоднозначного типа. --------- раз под subtyping - выделение типа понимается добавление аксиомы в спецификацию, то выбрасывание аксиомы из спецификации - это создание надтипа. выбросив из спецификации противоречивые аксиомы получим тип Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. вот к нему можно преобразовывать и объекты Ректангла и объекты Сквере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 20:24 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudiotchingizrstudioZyK_BotaNrstudio Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла какая ф-я принимающая целые числа не может принимать ноль? а какая ф-я принимающая прямоугольник не может принимать квадрат ? для юмористов Код: plaintext 1. 2. 3. 4. 5. Опять у когото потеют ладошки пронаследовать квадрат от прямоугольника. Я же выше сказал что прямоугольник не может быть базовым классом для квадрата. Что же он делает в параметрах твоей функции ? Там должен торчать нормальный базовый класс. вот так вот другое дело Код: plaintext 1. 2. 3. 0) это был ответ на твой вопрос, какая функция не может принять. Вот приведенная и не может принять. 1) дла особо наблюдательных - может быть базовым классом , ибо есть программа на с++ которая его так наследует. 2) о нежелательности такой программы, лет 15 уже как сообщил Роберт Мартин и это было до того, как ты сказал Более того, многие прочитали его мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 20:30 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
egorychZyK_BotaNв случае целых все будет ок?если в качестве делимого будет не ноль? - конечно. А что, есть сомнения в этом? )) к чему тогда было замечание про деление? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 20:38 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudio Опять у когото потеют ладошки пронаследовать квадрат от прямоугольника. Я же выше сказал что прямоугольник не может быть базовым классом для квадрата. Что же он делает в параметрах твоей функции ? Там должен торчать нормальный базовый класс. вот так вот другое дело Код: plaintext 1. 2. 3. 1 так вот такая функция, принимающая квадрат, не будет принимать прямоугольник при динамическом связывании Код: plaintext 1. 2. 3. 4. 5. во вторых, при наследовании Ректангла от Сквере, просто нельзя подставлять большую часть объектов от ребенка в переменные от родителя, ибо у них изначально нарушен инвариант с равенством сторон ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 20:42 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingiz 0) это был ответ на твой вопрос, какая функция не может принять. Вот приведенная и не может принять. Как же не может если может, чингиз, я тебя не узнаю. Если на вход подадут ректенгл с одинаковыми сторонами, она что бросит эксепшин и свернется ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 20:58 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingiz 1 так вот такая функция, принимающая квадрат, не будет принимать прямоугольник при динамическом связывании Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Разделяй что относится к квадрату, а что к ректенглу. У базового класса квадрат может быть определен только r.SetWidth(5). У ректенгла пронаследованого может быть определен еще r.SetHeight(4);. У куба SetLength и тд. Функционал наращиваем а не шпаклюем унивесальный базовый класс а у потомков только его подрезаем. [src] 2 во вторых, при наследовании Ректангла от Сквере, просто нельзя подставлять большую часть объектов от ребенка в переменные от родителя, ибо у них изначально нарушен инвариант с равенством сторон Открой для себя виртуальные функции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 21:06 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
с тегами чтото поломалось, вот сообщение Слушай, если ты так будешь писать квадраты они у тебя будут падать без всякого наследования и ректенглов [src]Square& r = new Square(); r.SetWidth(5); r.SetHeight(4); Разделяй что относится к квадрату, а что к ректенглу. У базового класса квадрат может быть определен только r.SetWidth(5). У ректенгла пронаследованого может быть определен еще r.SetHeight(4);. У куба SetLength и тд. Функционал наращиваем а не шпаклюем унивесальный базовый класс а у потомков только его подрезаем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 21:07 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Если бы ты читал, не только то, что ты пишешь, то уже знал бы, что квадраты и прямоугольники уже написаны Мартином. Обсуждаются трудности наследования на примере тех, которые уже написаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 21:16 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
авторУ базового класса квадрат может быть определен только r.SetWidth(5). У ректенгла пронаследованого может быть определен еще r.SetHeight(4); угу. а у целых можно определить только сложение, а у пронаследованных вещественных уже умножение ибо автор"Функционал наращиваем, а не шпаклюем унивесальный базовый класс а у потомков только его подрезаем" пысы это был сарказм, если что ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 21:22 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingizЕсли бы ты читал, не только то, что ты пишешь, то уже знал бы, что квадраты и прямоугольники уже написаны Мартином. Обсуждаются трудности наследования на примере тех, которые уже написаны. чтото я не понял, кто-то коряво написал а вы тут обсуждаете что с этим делать ? Понятное дело - переписывать по нормальному. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2010, 21:46 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudiotchingizЕсли бы ты читал, не только то, что ты пишешь, то уже знал бы, что квадраты и прямоугольники уже написаны Мартином. Обсуждаются трудности наследования на примере тех, которые уже написаны. чтото я не понял, кто-то коряво написал а вы тут обсуждаете что с этим делать ? Понятное дело - переписывать по нормальному.начальный топик прочитай, в первом сообщении есть ссылка, а то выглядишь сейчас глуповато ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 02:16 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNк чему тогда было замечание про деление?там специально было отцитировано, к чему. Функция, принимающая целые, но не принимающая ноль - это деление. Что именно осталось не понятым? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 02:18 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudio Граждане а как это у вас квадрат наследовал прямоугольник. Сам по себе класс прямоугольника прекрасно выполняет функции квадрата. Наследование обычно идет в сторону расширения возможностей, тоесть прямоугольник может расширить квадрат. оффтопик Если отвлечься от обсуждаемого примера, и на секундочку глянуть в начало ооп, то можно вспомнить, что пытались добиться того, что множество объекта класса ребенка входило бы подмножеством в множество объектов класса родителя. ссылка на лекцию Мейера, где он наследовал квадраты от прямоугольников http://www.intuit.ru/department/se/oopbases/14/1.html и картинка (если кто читать не может) наследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет, ибо прямоугольники не входят подмножеством во множество квадратов. Только сумашедший начнет наследовать прямоугольники от квадратов. (равно как и рациональные от целых ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 03:58 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingizнаследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,ибо прямоугольники не входят подмножеством во множество квадратов. Только сумашедший начнет наследовать прямоугольники от квадратов. (равно как и рациональные от целых ) Не согласен.И Мейер об это не писал. Наследовать прямоугольник от квадрата можно, Наследовать рациональные от целых можно. И то и то ослабляет инвариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 08:29 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingiz наследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет, ибо прямоугольники не входят подмножеством во множество квадратов. Только сумашедший начнет наследовать прямоугольники от квадратов. (равно как и рациональные от целых ) Я чето не понял твой репертуар чингиз. Ты говоришь что в теории от прямоугольника можно пронаследовать квадрат, очевидно руководствуясь этой логикой от квадрата по логике пронаследуешь линию, а от линии точку ?Где такое пишут, дай почитать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 12:46 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
От прамоугольника можно наследоваться квадрату: углы прямые. В качестве расширения добавляется ещё и свойство равенства сторон. Но не наоборот. Квадрат - по определению прамоугольник с равными сторонами. При чём здесь линия, у которой даже углов нет, не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 12:57 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ShSergeОт прамоугольника можно наследоваться квадрату: углы прямые. В качестве расширения добавляется ещё и свойство равенства сторон. а ничо что тогда класс ректенгл у тебя будет абстрактным ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 13:02 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Siemargltchingizнаследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,ибо прямоугольники не входят подмножеством во множество квадратов. Только сумашедший начнет наследовать прямоугольники от квадратов. (равно как и рациональные от целых ) Не согласен.И Мейер об это не писал. Наследовать прямоугольник от квадрата можно, Наследовать рациональные от целых можно. И то и то ослабляет инвариант. в этом и проблема, что расслабляет, а должно быть наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 15:29 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudio очевидно руководствуясь этой логикой от квадрата по логике пронаследуешь линию, а от линии точку ?Где такое пишут, дай почитать неверная у тебя логика. линия не является квадратом. квадрат является прямоугольником. так понятно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 15:30 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudioShSergeОт прамоугольника можно наследоваться квадрату: углы прямые. В качестве расширения добавляется ещё и свойство равенства сторон. а ничо что тогда класс ректенгл у тебя будет абстрактным ? вспомнилось Дуг МакИлрой Эти типы совсем не "абстрактные", они настолько же реальны, и int и float . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 15:34 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNrstudio очевидно руководствуясь этой логикой от квадрата по логике пронаследуешь линию, а от линии точку ?Где такое пишут, дай почитать неверная у тебя логика. линия не является квадратом. квадрат является прямоугольником. так понятно? Чтобы хранить базовый класс нужно 2х байт, чтобы хранить его наследника нужно Х байт, а чтобы хранить линию достаточно Х/2 байт. Чтобы хранить наследника линии, точку, нужны Х/4 байт. Все сходится :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 15:47 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNSiemargltchingizнаследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,ибо прямоугольники не входят подмножеством во множество квадратов. Только сумашедший начнет наследовать прямоугольники от квадратов. (равно как и рациональные от целых ) Не согласен.И Мейер об это не писал. Наследовать прямоугольник от квадрата можно, Наследовать рациональные от целых можно. И то и то ослабляет инвариант. в этом и проблема, что расслабляет, а должно быть наоборот. Примерчик для опровержения? Now the rule for the preconditions and postconditions for derivatives, as stated by Meyer3, is: "...when redefining a routine [in a derivative], you may only replace its precondition by a weaker one, and its postcondition by a stronger one." In other words, when using an object through its base class interface, the user knows only the preconditions and postconditions of the base class. Thus, derived objects must not expect such users to obey preconditions that are stronger then those required by the base class. That is, they must accept anything that the base class could accept. Also, derived classes must conform to all the postconditions of the base. That is, their behaviors and outputs must not violate any of the constraints established for the base class. Users of the base class must not be confused by the output of the derived class. Clearly, the postcondition of Square::SetWidth(double w) is weaker than the postcondition of Rectangle::SetWidth(double w) above, since it does not conform to the base class clause “(itsHeight == old.itsHeight)”. Thus, Square::SetWidth(double w) violates the contract of the base class. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 15:56 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
rstudioZyK_BotaNrstudio очевидно руководствуясь этой логикой от квадрата по логике пронаследуешь линию, а от линии точку ?Где такое пишут, дай почитать неверная у тебя логика. линия не является квадратом. квадрат является прямоугольником. так понятно? Чтобы хранить базовый класс нужно 2х байт, чтобы хранить его наследника нужно Х байт, а чтобы хранить линию достаточно Х/2 байт. Чтобы хранить наследника линии, точку, нужны Х/4 байт. Все сходится :) нет не сходится. сколько хранится бай - не известно(инкапусаляция, одному разрабу известно как он реализовал данный тип). главное интерфейс. в моей реализации, для хранения квадрата были взяты те же 2х байта, что и для прямоугольника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 16:03 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
thingizВозьмем в $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. Выделено красным. Из одной неверной предпосылки не следует ложность другой. 2. Не надо смешивать LSP и контракты Мейерса. Подтипы отностятся к LSP, но не к Мейерсу. LSPWhat is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. P(T) .eq. P(S) when S.is subtype(T) Что считать подтипом? Похоже, что производный класс всегда является подтипом. И тогда нужно аккуратно совместить LSP, где утверждение про подтипы и - контракты, где про производные классы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 16:46 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
1) иерархия типов определяется законами логики из заданных аксиом, то есть, дана Богом и не может быть изменена. 2) иерархия классов определятся произволом программиста, и может быть перекручена, чуть ли не в произвольном порядке. 3) соответствие иерархий выполняется тогда, когда для каждой пары подкласс - надкласс спецификация подкласса является подтипом спецификации надкласса. 4) проверка типов в компиляторе гарантирует работу программы только тогда, когда иерархия типов соответствует иерархии классов. 5) принципы дизайна по контракту создают иерархии классов соответствующие иерархиями типов. точка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2010, 18:22 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
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. Выделено красным. Из одной неверной предпосылки не следует ложность другой. это не посылки, это следствия из аксиом. Из одной аксиомы строится один класс, из другой - второй. аксиомы не совместимы и равнозначны. Классы в этом смысле одинаковы - значение переменной одного класса не может быть присвоено в переменную другого и наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2010, 07:34 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Siemargl Что считать подтипом? Похоже, что производный класс всегда является подтипом. И тогда нужно аккуратно совместить LSP, где утверждение про подтипы и - контракты, где про производные классы. тип - это спецификация, то есть, список аксиом. подтип - более длинный список аксиом, содержащий родительский список. Принцип подстановки Лисков меня уже не волнует, у меня свой критерий, лучше есть. http://www.sql.ru/forum/actualthread.aspx?tid=800476&pg=10#9707022 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2010, 07:37 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingizSiemarglпропущено... Мне кажется, уважаемый Чингиз, что ты таки ошибаешься в двух местах: 1. Выделено красным. Из одной неверной предпосылки не следует ложность другой. это не посылки, это следствия из аксиом. Из одной аксиомы строится один класс, из другой - второй. аксиомы не совместимы и равнозначны. Классы в этом смысле одинаковы - значение переменной одного класса не может быть присвоено в переменную другого и наоборот. В твоих аксиомах противоречия для наследования прямоугольника от квадрата нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2010, 08:39 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Ладно, для прямоугольника я могу придумать опровержение. Программа, которая умеет работать с квадратами и полагается на равенство сторон, опрокинется если получит прямоугольник. Остается второе утверждение: Наследовать рациональные от целых можно. Что то мне кажется, что жестко подходя к принципам - невозможно вообще ничего отнаследовать ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2010, 09:27 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
SiemarglЧто то мне кажется, что жестко подходя к принципам - невозможно вообще ничего отнаследовать )))Нашел ответ у Александреску - базовый класс должен задавать настолько мягкие ограничения, насколько возможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2010, 09:54 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Siemargltchingizнаследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,ибо прямоугольники не входят подмножеством во множество квадратов. Только сумашедший начнет наследовать прямоугольники от квадратов. (равно как и рациональные от целых ) Не согласен.И Мейер об это не писал. Наследовать прямоугольник от квадрата можно, Наследовать рациональные от целых можно. И то и то ослабляет инвариант. Уговорили. И вправду чушь написал -) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2010, 10:17 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingizКлассы в этом смысле одинаковы - значение переменной одного класса не может быть присвоено в переменную другого и наоборот. Переменной надтипа можно присвоить значение подтипа. При этом переменная должна изменить свой тип на подтип (т.е. тип объекта сохраняется). Наоборот нельзя - компилятор не пропустит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2010, 09:36 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
аналогичный трехлетний окружностесрач на 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" есть статья про модель наследования, так там он когда разбирает статью Лисков, все время сокрушается, что "объект" у нее означает и текущее значение переменной, и саму переменную, что так и не указаны отличия между "классом" и "типом" — или не сказано, что это синонимы, и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2011, 19:48 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Тут у меня единодушное мнение со Страуструпом - я тоже пытался говорить, что класс RSquare не имеет ничего общего с квадратами из математики, поэтому аппеляция к геометрическому смыслу бессмысленна. Далее, Страуструп говорит о проектировании, что если надо спроектировать классы. Я пытался решить чисто технический вопрос уже есть класс Rectangle и класс Square из статьи Мартина (и именно такие как у Мартина и никакие другие) и для них написано пять триллионов шесть миллиардов пятсот тридцать одна программа. Что будет если наследовать один из другого? Наследовать можно, но поскольку один из классов не является подтипом другого, теряется проверка типов. Вместо переменной родителя можно подставить переменную ребенка - компилятор пропустит, а на шаге выполнения задача сбойнет. -- заодно определения типизация - это свойство-средства языка, гарантирующее успешное вычисление корректного выражения. полиморфизм - это свойство-средство языка, гарантирующее успешное вычисление корректного выражения для множества типов мощности больше одного. Таким образом получаем, что с++ не вполне полиморфен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2011, 19:57 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
после квадратов и прямоугольников, над окружностями и эллипсами я раздумывал, но решил что натуральные, целые и рациональные - более лучшие примеры. К ним не может быть претензий по поводу плохого проектирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2011, 19:59 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
а че тут думать? для неизменяемых объектов, квадрат можно использовать вместо прямоугольника - ковариантность. для изменяемых объектов так делать нельзя - инвариантность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2011, 20:42 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingiz заодно определения типизация - это свойство-средства языка, гарантирующее успешное вычисление корректного выражения. полиморфизм - это свойство-средство языка, гарантирующее успешное вычисление корректного выражения для множества типов мощности больше одного. Таким образом получаем, что с++ не вполне полиморфен. последнее улучшение. )) полиморфизм это свойство-средство языка позволяющее записывать корректные выражения для более чем одного типа (множества типов мощности больше один) дословный перевод из Милнера - возможность трактовать некоторые термы, как принадлежащие многим различным типам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2011, 15:03 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
из работы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2011, 15:04 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
отдельное спасибо Максиму Талдыкину ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2011, 15:05 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
tchingiz, да, но полиморфизм - полиморфизму рознь. мы ведь про ad-hoc полиморфизм говорим? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2011, 15:06 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
когда я говорю специальный, я так и пишу специальный полиморфизм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2011, 15:09 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
частные случаи полиморфизма должны удовлетворять определению общего случая. Как и частные случаи любого понятия должны удовлетворять определению общего случая того же понятия. Например, квадрат частный случай прямоугольника, и квадрат удовлетворяет определению прямоугольника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2011, 15:11 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
вот на счет контрактов часто жалуются. а что толку от контрактов, если они не проверяются на практике. дак вот, встретил на рсдн хороший пост: http://rsdn.ru/forum/decl/4522924.flat.aspx там правда примеры сложноватые для нехаскелистов, поэтому как будет время(на днях), напишу пару игрушечных примера. что бы без разных монадныых трансформеров суть топика такова. параметризируем монаду двумя типами: пост- и пред- условиями. что получаем на практике - проверку контракта в момент компиляции. пример(игрушечную модель которого я напишу сегодня или завтра): есть у нас файл. в него можно писать, только если он открыт для записи. закрывать только если он открыт. и если он закрыт, то писать в него нельзя. что нам предлагают современные языки(а вернее их библиотеки). если мы попытаемся писать в закрытый файл, то получим исключение в рантайме. но параметризированные монады позволяют отловить данную ошибку - в момент компиляции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2012, 21:52 |
|
||
|
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
|
|||
|---|---|---|---|
|
#18+
Я пишу постоянно на контрактах, делается это так, объявляешь интерфейс и передаешь в зависимые классы только тип. В результате каждый класс можно тестировать отдельно, дописываешь внизу тестовый метод и готово. Как результат, архитектура становится намного прозрачней и читабельной для других, в больших проектах и самому ориентироваться легче. Кроме того, использование контрактов открывает широкие возможности для атрибутов. Объявил атрибуты, если классы в разных либах, компилятор их объединит в общий тип, что позволяет тянуть схему выполнения не класс за классом, а в произвольном, нужном порядке, например, сначала в одном потоке вызывать код, а только потом уже поднимать форму совсем в другом потоке и передавать туда инфу. Достоинств много, всего сразу и не перечислишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2013, 05:57 |
|
||
|
|

start [/forum/topic.php?all=1&fid=16&tid=1341820]: |
0ms |
get settings: |
8ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
158ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 194ms |
| total: | 436ms |

| 0 / 0 |
