|
|
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
Siemarglegorych, Да. Но это чуть другое из DbC. -Изменение ширины не влияет на значение длины - это отсутствие побочных эффектов.в то время как у квадрата побочный эффект обязателен. Изменение "ширины" _должно_ приводить к изменению "длины" ( кавычки тут к тому, что у квадрата сложно выделить ширину и длину :) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 17:05 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
egorychSiemarglИнварианты могут разными, в зависимости от задачи: -вариант 1. Все стороны равны. -вариант 2. Все углы прямые -вариант 3. Сторон не больше 4х.-вариант 4. Величины длины и ширины могут меняться независимо да. SetWidth(Square(5), 10) вернет значение Rectangle(10, 5) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 18:47 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNSetWidth(Square(5), 10) вернет значение Rectangle(10, 5)это смотря как реализована SetWidth(). Если, что логично, она будет спрашивать встроенный метод Rectangle.SetWidth(), то вернёт вполне себе квадрат ( 10, 10 ), иначе или SetWidth должна знать, кого ей передают, или реализация Square::SetWidth() должна быть очень необычна ( и нарушать принцип наименьшего удивления при этом ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 19:57 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
egorychZyK_BotaNSetWidth(Square(5), 10) вернет значение Rectangle(10, 5)это смотря как реализована SetWidth(). Если, что логично, она будет спрашивать встроенный метод Rectangle.SetWidth(), то вернёт вполне себе квадрат ( 10, 10 ), иначе или SetWidth должна знать, кого ей передают, или реализация Square::SetWidth() должна быть очень необычна ( и нарушать принцип наименьшего удивления при этом ) Ну вот код: Код: 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. в результате будет вывод: Square(5.0,5.0) Rectangle(10.0,5.0) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 20:24 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
подправил класс Square: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. теперь программа: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Square(5.0) Rectangle(10.0,5.0) Square(3.0) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 20:33 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
_модtchingizВ дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование. Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника. не правильно. 1) Область определения функций (методов класса) была сужена. (У прямоугольников была плоскость, у квадратов диагональ плоскости.) 2) методы у так называемого ребенка - квадратов удовлетворяют аксиомам противоречащим аксиомам методов так называемого родителя - прямоугольников. поэтому, оказалось невозможное корректное выполнение цепочка а) преобразование из ребенка в родителя б) выполнение метода в) восстановление ребенка взад. если на шаге б) выполнялся метод родителя, нарушался инвариант ребенка. если на шаге б) выполнялся метод ребенка, нарушались условия, выполнения функций (клиента), которые были написаны в предположении аксиом родителя. пысы. поскольку сам Карделли разрешил использовать наивную модель памяти при толковании ооп, в которой обьект это пара (кортеж, множество_методов), то моя функциональная запись классов и обьектов в виде абстрактных автоматов оказывается точным описанием. (класс это пара (множество_допустимых_значений, множество_функций), объект - это пара (кортеж , множество_функций)) А проблема не возможности наследования остается все равно. Так что функциональность тут не причем. Дело в несовместимости аксиом описания классов, совмещением которых и занят Мейер в своем методе программирования по контракту ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 21:15 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
вот аксиомы обоих классов http://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=4#9543464 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 21:18 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaN, красиво, но у меня 2 замечания: 1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый 2. вообще говоря, я ведь могу захотеть сделать Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 21:33 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
tchingiz, Ну пц, пояснил ))))) Еще хуже стало. Если я понял правильно, то для решения проблем преобразования "родственников" есть виртуальные ф-ции. Инвариант ес-но, тоже должен быть виртуальным. И еще мне кажется, что "теорию происхождения видов" неправильно привязывать к ООП - суть разная. (Майерса не читал, что он имел в виду - не знаю) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 21:44 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
egorychZyK_BotaN, красиво, но у меня 2 замечания: 1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый 2. вообще говоря, я ведь могу захотеть сделать Код: plaintext 1. перечитай исправленную версию: Код: plaintext 1. что мне не нравится в моем коде, дак это метод show. я его написал, что-бы короче было. лучше было бы написать два метода showSquare и showRectangle ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 21:56 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
Siemargltchingiz, Ну пц, пояснил ))))) Еще хуже стало. Если я понял правильно, то для решения проблем преобразования "родственников" есть виртуальные ф-ции. Инвариант ес-но, тоже должен быть виртуальным. И еще мне кажется, что "теорию происхождения видов" неправильно привязывать к ООП - суть разная. (Майерса не читал, что он имел в виду - не знаю) 1 не правильно. для решения проблем родственников - нужны совместимые системы аксиом. 2 у прямоугольников аксиома говорит о не зависимости методов Код: plaintext 1. равно гетШирина(ф), взятие ширины не зависит от применения установить длину. а у квадратов зависит Код: plaintext 1. 2. шо тут непонятно? сначала создается родитель. Потом к родителю пишутся вызывающие программы, которые используют родителя. Они пишутся в предположении, что выполняются его аксиомы. Потом ты пишешь ребенка, херишь аксиомы родителя, и подсовываешь тем программам, которые написаны в предположении похереных аксиом ребенка под видом родителя. В результате клиент умирает от удивления. Нарушен принцип подстановки Лисков. 3 не Майерс, а Бертран Мейер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 22:10 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
В результате клиент умирает от удивления, со словами: "а мы так не договаривались" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 22:14 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
Более того, точно такой же техникой на с++, какой записывалось порождение квадратов из прямоугольников, можно записать порождение прямоугольников из квадратов. с точно той же проблемой не соответствия аксиом. Эти классы не ребенок и родитель, а два близнеца. Их не надо, вообще, один из другого порождать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 22:22 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
tchingiz, как только ты делаешь квадрату setWidth он перестает быть квадратом. Надо просто в объектную модель ввести predicate classes как в языке cecil . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 22:29 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
belugintchingiz, как только ты делаешь квадрату setWidth он перестает быть квадратом. Надо просто в объектную модель ввести predicate classes как в языке cecil . конечно, я это выше и продемонстрировал с примерами кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 22:35 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
под словом квадрат я не имею ввиду ничего другого кроме как объекты обсуждаемого класса Square. Они заданы однозначно и совершенно понятно формальным описанием на с++ в примера Роберта Мартина. После вызова функций setWidth из своего класса, квадрат квадратом быть не перестает. Это переменная, объявленная классом, возможно, оказавшаяся в противоречивом состоянии.. И обсуждается смысл техники программирования, а не смысл геометрических фигур на плоскости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 22:39 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
tchingizпод словом квадрат я не имею ввиду ничего другого кроме как объекты обсуждаемого класса Square. Они заданы однозначно и совершенно понятно формальным описанием на с++ в примера Роберта Мартина. а чем тебе не понравилась моя реализация фигур? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 22:52 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
а что ты хотел добиться? А то я недопонял пока Перестал нарушаться принцип Лисков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 23:17 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
tchingizа что ты хотел добиться? А то я недопонял пока Перестал нарушаться принцип Лисков? если игнорировать метод show, то да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 23:25 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
tchingiz, Пока не прочитал статью Лисковой, не понятно было о чем вы говорите ) Теперь возвращаюсь к своему же предыдущему утверждению: инварианты (аксиоматика) связана с наследованием, и обязательна к учитыванию при проектировании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2010, 23:50 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
естественно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 00:44 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
Статья не Лисков, а Мартина ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 00:45 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
ZyK_BotaNtchingizа что ты хотел добиться? А то я недопонял пока Перестал нарушаться принцип Лисков? если игнорировать метод show, то да. не понял, что да. ты написал в функциональном стиле. Мне кажется, что это означает что цепочка Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. вопрос, в том, что 1) все ранее, написанные программы работают при применении методов, если подсунуть ребенка, под видом родителя; 2) можно выполнить обратное преобразование родитель -> ребенок, после применения методов, когда ребенок был под видом родителя. у тебя нет обратного преобразования. А в примере Мартина оно неявно требуется, при в начальном обсуждении, когда выполнялось статическое связывание. вот это главное, Код: plaintext Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 01:04 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
tchingizZyK_BotaNtchingizа что ты хотел добиться? А то я недопонял пока Перестал нарушаться принцип Лисков? если игнорировать метод show, то да. не понял, что да. только метод show нарушает принцип Лисков. tchingiz ты написал в функциональном стиле. Мне кажется, что это означает что цепочка Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. здесь можно подробней? я не понял. tchingiz у тебя нет обратного преобразования. А в примере Мартина оно неявно требуется, при в начальном обсуждении, когда выполнялось статическое связывание. вот это главное, Код: plaintext Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все. тогда с потерей точности будет работать. но тогда преобразование нужно делать явно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 01:21 |
|
||
|
Выгоды контрактного программирования (design by contract)
|
|||
|---|---|---|---|
|
#18+
tchingiz вот это главное, Код: plaintext Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все. Код: 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. вывод: Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 01:28 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=36919054&tid=1343356]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
196ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
78ms |
get tp. blocked users: |
1ms |
| others: | 219ms |
| total: | 542ms |

| 0 / 0 |
