ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Выгоды контрактного программирования (design by contract)
232 сообщений из 232, показаны все 10 страниц
  все  
Выгоды контрактного программирования (design by contract)
    #36916999
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Обсуждение технологии. Зачем она нужна в практических применениях.
Описание тут
http://ru.wikipedia.org/wiki/Контрактное_программирование

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

Альтернативное мнение.
Гаджимурадов РустамP.S. Для несведущих - это всего лишь очередной лозунг.
Маркетинга там в разы больше, чем пользы. А в тех
случаях, когда это действительно нужно, оно, в общем-то,
применялось задолго до появления самого лозунга.
...
Рейтинг: 0 / 0
24.10.2010, 23:31
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36917011
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
Ну, Рустам мастер сам лозунгами бросаться.
В дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.
Потому, что сужается область определения функций SetWidth. Нарушается простое формальное правило.
А другие авторы, включая Роберта Мартина, нагоняют мистический ооп туман.


///topic/756625&pg=5#9543547
// http://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=5#9590420
...
Рейтинг: 0 / 0
24.10.2010, 23:50
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36917569
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingizВ дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.
...
Рейтинг: 0 / 0
25.10.2010, 11:51
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36917620
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
_модtchingizВ дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.так же как и подтип ромба. Так чего же выбрать?
...
Рейтинг: 0 / 0
25.10.2010, 12:05
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36917750
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
egorychтак же как и подтип ромба. Так чего же выбрать?
А не надо ничго выбирать. Просто методы ромба можно попытаться применить к квадрату.
...
Рейтинг: 0 / 0
25.10.2010, 12:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36917767
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
_модegorychтак же как и подтип ромба. Так чего же выбрать?
А не надо ничго выбирать. Просто методы ромба можно попытаться применить к квадрату.
а нафига все эти нагромаждения?
нет никаких методов ни у ромба ни у квадрата ни какого то угольника
...
Рейтинг: 0 / 0
25.10.2010, 13:01
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36917933
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych_модtchingizВ дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.так же как и подтип ромба. Так чего же выбрать?
множественное наследование
...
Рейтинг: 0 / 0
25.10.2010, 13:40
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918017
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNмножественное наследованиеэто чтобы запутаться окончательно :-)) и ещё, до кучи, виртуально отнаследоваться от класса "четырёхугольники"
...
Рейтинг: 0 / 0
25.10.2010, 14:06
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918044
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
ViPRosнет никаких методов ни у ромба ни у квадрата ни какого то угольника
Это верно. Есть процедуры/функции, у которых параметры имеют заданный тип (например прямоугольник). Их можно применять к подтипам (к квадратам), но с учетом инвариантов подтипа (равенство сторон).
...
Рейтинг: 0 / 0
25.10.2010, 14:15
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918051
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNмножественное наследованиеэто чтобы запутаться окончательно :-)) и ещё, до кучи, виртуально отнаследоваться от класса "четырёхугольники"
уже неявно это сделали.
от читырех угольников и равносторонних фигур отнаследовали ромб.
от равноугольного многоугольника и четырехугольника отнаследовали прямоугольник.
от от ромба и прямоугольника отнаследовали квадрат.

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

также при вызове конструктора Rectangle(w = 5, h = 5), будет создан прямоугольник, а не квадрат, аналогично тому что 1.0 - double, а не int.
...
Рейтинг: 0 / 0
25.10.2010, 14:16
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918062
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
_модViPRosнет никаких методов ни у ромба ни у квадрата ни какого то угольника
Это верно. Есть процедуры/функции, у которых параметры имеют заданный тип (например прямоугольник). Их можно применять к подтипам (к квадратам), но с учетом инвариантов подтипа (равенство сторон).
если ввести понятия иммутабельности, то метод работающий с прямоугольником, не обязан знать о существовании типа квадрат, все по аналогии с примитивными типами double и int.
если в ф-ю корня передать целое число, то она вернет значиние типа double.
так и тут, если метод возвращает модифицированную фигуру(например увеличивает ширину в 2 раза), то никаких проблем не будет.
...
Рейтинг: 0 / 0
25.10.2010, 14:21
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918177
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
ZyK_BotaNметод работающий с прямоугольником, не обязан знать о существовании типа квадрат
конечно, не обязан
ZyK_BotaNесли в ф-ю корня передать целое число, то она вернет значиние типа double.
так и тут, если метод возвращает модифицированную фигуру(например увеличивает ширину в 2 раза), то никаких проблем не будет.
Со значениями функций проблем нет - они возвращают заданный для них тип. Проблемы есть при передаче параметром подтипа вместо заданного типа - может сработать инвариант подтипа и процедура выдаст ошибку.
...
Рейтинг: 0 / 0
25.10.2010, 15:00
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918189
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN,

Иммутабельность тут ни при чем. Начали с проверки инвариантов объекта.

Инварианты могут разными, в зависимости от задачи:
-вариант 1. Все стороны равны.
-вариант 2. Все углы прямые
-вариант 3. Сторон не больше 4х.

Структура инвариантов должна идти строго параллельно со структурой наследования.
...
Рейтинг: 0 / 0
25.10.2010, 15:04
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918196
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
_модПроблемы есть при передаче параметром подтипа вместо заданного типа - может сработать инвариант подтипа и процедура выдаст ошибку.
я уже выше написал - решение неизменяемость объектов.

или я я заблуждаюсь? укажи мне пример, где будет ошибка.
...
Рейтинг: 0 / 0
25.10.2010, 15:06
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918204
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
_модСо значениями функций проблем нет - они возвращают заданный для них тип. Проблемы есть при передаче параметром подтипа вместо заданного типа - может сработать инвариант подтипа и процедура выдаст ошибку.
1. Это на уровне языка должно быть определено (забыл термин), что допускается возвращать наследников.
2. Если даже возвращается родительский тип, будет проверен инвариант этого типа. И ошибки не будет.

Если наследуются типы с инвариантами, проверяются все инварианты всех родителей. По очереди.
...
Рейтинг: 0 / 0
25.10.2010, 15:07
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918206
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,

Иммутабельность тут ни при чем. Начали с проверки инвариантов объекта.

Инварианты могут разными, в зависимости от задачи:
-вариант 1. Все стороны равны.
-вариант 2. Все углы прямые
-вариант 3. Сторон не больше 4х.

Структура инвариантов должна идти строго параллельно со структурой наследования.

ну у квадрата все стороны равны, какому из инвариантов прямоугольника это противоречит?
...
Рейтинг: 0 / 0
25.10.2010, 15:07
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918231
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN,

Если наследник - прямоугольник, то подходят 2 и 3.
Если наследник ромб - то 1 и 3.

А кто будет наследником у прямоугольника или ромба???
Тогда может и будет окончательный выбор.
...
Рейтинг: 0 / 0
25.10.2010, 15:18
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918241
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,

Если наследник - прямоугольник, то подходят 2 и 3.
Если наследник ромб - то 1 и 3.

чей наследник?

Siemargl
А кто будет наследником у прямоугольника или ромба???

например квадрат.
...
Рейтинг: 0 / 0
25.10.2010, 15:21
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918313
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN,

Я пример приводил, если квадрат - родитель. Ну я думаю, что идею пояснил.
...
Рейтинг: 0 / 0
25.10.2010, 15:43
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918373
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
ZyK_BotaNя уже выше написал - решение неизменяемость объектов.
Это да. Только это уже чисто функциональное программирование.
...
Рейтинг: 0 / 0
25.10.2010, 16:01
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918393
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,

Я пример приводил, если квадрат - родитель. Ну я думаю, что идею пояснил.
а, тогда все ок.
квадрат ведь не родитель, а дочерний класс классов ромб и прямоугольник.
...
Рейтинг: 0 / 0
25.10.2010, 16:06
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918446
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
SiemarglИнварианты могут разными, в зависимости от задачи:
-вариант 1. Все стороны равны.
-вариант 2. Все углы прямые
-вариант 3. Сторон не больше 4х.-вариант 4. Величины длины и ширины могут меняться независимо
...
Рейтинг: 0 / 0
25.10.2010, 16:26
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918459
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
egorychSiemarglИнварианты могут разными, в зависимости от задачи:
-вариант 1. Все стороны равны.
-вариант 2. Все углы прямые
-вариант 3. Сторон не больше 4х.-вариант 4. Величины длины и ширины могут меняться независимо
Где тут инвариант = условие для проверки?
...
Рейтинг: 0 / 0
25.10.2010, 16:31
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918483
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
SiemarglГде тут инвариант = условие для проверки?ну да, не инвариант, но постусловие для соответстующего сеттера
-Изменение ширины не влияет на значение длины
-Изменение длины не влияет на значение ширины
их мы тоже в DbC надо проверять, кмк?
...
Рейтинг: 0 / 0
25.10.2010, 16:39
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918496
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
egorych,

Да. Но это чуть другое из DbC.
-Изменение ширины не влияет на значение длины - это отсутствие побочных эффектов.

А инвариант - это корректность объекта в целом. Т.е. например, инвариантом может допускаться side effect, если после вызова объет остался верен инварианту, например квадратом (пусть и увеличенным вдвое).
...
Рейтинг: 0 / 0
25.10.2010, 16:45
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918555
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
Siemarglegorych,

Да. Но это чуть другое из DbC.
-Изменение ширины не влияет на значение длины - это отсутствие побочных эффектов.в то время как у квадрата побочный эффект обязателен. Изменение "ширины" _должно_ приводить к изменению "длины" ( кавычки тут к тому, что у квадрата сложно выделить ширину и длину :) )
...
Рейтинг: 0 / 0
25.10.2010, 17:05
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918828
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychSiemarglИнварианты могут разными, в зависимости от задачи:
-вариант 1. Все стороны равны.
-вариант 2. Все углы прямые
-вариант 3. Сторон не больше 4х.-вариант 4. Величины длины и ширины могут меняться независимо

да.

SetWidth(Square(5), 10)
вернет значение
Rectangle(10, 5)
...
Рейтинг: 0 / 0
25.10.2010, 18:47
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918937
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNSetWidth(Square(5), 10)
вернет значение
Rectangle(10, 5)это смотря как реализована SetWidth(). Если, что логично, она будет спрашивать встроенный метод Rectangle.SetWidth(), то вернёт вполне себе квадрат ( 10, 10 ), иначе или SetWidth должна знать, кого ей передают, или реализация Square::SetWidth() должна быть очень необычна ( и нарушать принцип наименьшего удивления при этом )
...
Рейтинг: 0 / 0
25.10.2010, 19:57
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918976
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
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.
public class Rectangle {
	private double w,h;
	Rectangle(double w, double h) {
		this.w = w;
		this.h = h;
	}
	Rectangle setWidth(double newW) {
		return new Rectangle(newW, h);
	}
	Rectangle setHeight(double newH) {
		return new Rectangle(w, newH);
	}
	double getWidth() {
		return w;
	}
	double getHeight() {
		return h;
	}
	void show() {
		System.out.println("Rectangle("+getWidth()+","+getHeight()+")");
	}
}



public class Square extends Rectangle {
	Square(double side) {
		super(side, side);
	}
	void show() {
		System.out.println("Square("+getWidth()+","+getHeight()+")");
	}
}


public class Main {
	public static void main(String[] args) {
		Square s = new Square( 5 );
		Rectangle r = s.setWidth( 10 );
		s.show();
		r.show();
	}
}

в результате будет вывод:

Square(5.0,5.0)
Rectangle(10.0,5.0)
...
Рейтинг: 0 / 0
25.10.2010, 20:24
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36918985
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
подправил класс Square:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
public class Square extends Rectangle {
	Square(double side) {
		super(side, side);
	}
	Square setSide(double newSide) {
		return new Square( newSide );
	}
	void show() {
		System.out.println("Square("+getWidth()+")");
	}
}

теперь программа:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
public class Main {
	public static void main(String[] args) {
		Square s = new Square( 5 );
		Rectangle r = s.setWidth( 10 );
		s.show();
		r.show();
		s = s.setSide( 3 );
		s.show();
	}
}
выдает:
Square(5.0)
Rectangle(10.0,5.0)
Square(3.0)
...
Рейтинг: 0 / 0
25.10.2010, 20:33
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919026
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
_модtchingizВ дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.
не правильно.
1)
Область определения функций (методов класса) была сужена.
(У прямоугольников была плоскость, у квадратов диагональ плоскости.)
2)
методы у так называемого ребенка - квадратов удовлетворяют аксиомам противоречащим
аксиомам методов так называемого родителя - прямоугольников.
поэтому, оказалось невозможное корректное выполнение цепочка
а) преобразование из ребенка в родителя
б) выполнение метода
в) восстановление ребенка взад.

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

пысы.
поскольку сам Карделли разрешил использовать наивную модель памяти при толковании
ооп, в которой
обьект это пара (кортеж, множество_методов), то
моя функциональная запись классов и обьектов в виде
абстрактных автоматов оказывается точным описанием.
(класс это пара (множество_допустимых_значений, множество_функций),
объект - это пара (кортеж , множество_функций))
А проблема не возможности наследования остается все равно.
Так что функциональность тут не причем.
Дело в несовместимости аксиом описания классов, совмещением которых
и занят Мейер в своем методе программирования по контракту
...
Рейтинг: 0 / 0
25.10.2010, 21:15
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919031
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
вот аксиомы обоих классов
http://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=4#9543464
...
Рейтинг: 0 / 0
25.10.2010, 21:18
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919054
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.SetWidth(  10  ); // опа!
...
Рейтинг: 0 / 0
25.10.2010, 21:33
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919074
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
tchingiz,

Ну пц, пояснил )))))
Еще хуже стало.

Если я понял правильно, то для решения проблем преобразования "родственников" есть виртуальные ф-ции. Инвариант ес-но, тоже должен быть виртуальным.
И еще мне кажется, что "теорию происхождения видов" неправильно привязывать к ООП - суть разная. (Майерса не читал, что он имел в виду - не знаю)
...
Рейтинг: 0 / 0
25.10.2010, 21:44
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919086
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.SetWidth(  10  ); // опа!

перечитай исправленную версию:

Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.setSide(  10  ); // опа!
[/quot]

что мне не нравится в моем коде, дак это метод show.
я его написал, что-бы короче было. лучше было бы написать два метода
showSquare и showRectangle
...
Рейтинг: 0 / 0
25.10.2010, 21:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919100
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
Siemargltchingiz,

Ну пц, пояснил )))))
Еще хуже стало.

Если я понял правильно, то для решения проблем преобразования "родственников" есть виртуальные ф-ции. Инвариант ес-но, тоже должен быть виртуальным.
И еще мне кажется, что "теорию происхождения видов" неправильно привязывать к ООП - суть разная. (Майерса не читал, что он имел в виду - не знаю)
1
не правильно. для решения проблем родственников - нужны совместимые
системы аксиом.
2
у прямоугольников аксиома говорит о не зависимости методов
Код: plaintext
1.
 all h: UReal, f: Figure:- GetWidth(SetHeight(f, h)) = GetWidth(f)
для любого вещественного х, и любой фигуры ф, гетШирина(сетДлина(ф,х))
равно гетШирина(ф), взятие ширины не зависит от применения установить длину.

а у квадратов зависит
Код: plaintext
1.
2.
,[gw_sh]
        all h: UReal, f: Figure:- GetWidth(SetHeight(f, h)) = h
взятьширину возвращает, то что задано задатьдлину.

шо тут непонятно?

сначала создается родитель. Потом к родителю пишутся вызывающие программы,
которые используют родителя. Они пишутся в предположении, что выполняются
его аксиомы.
Потом ты пишешь ребенка, херишь аксиомы родителя, и подсовываешь тем
программам, которые написаны в предположении похереных аксиом
ребенка под видом родителя.
В результате клиент умирает от удивления. Нарушен принцип подстановки Лисков.

3
не Майерс, а Бертран Мейер.
...
Рейтинг: 0 / 0
25.10.2010, 22:10
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919107
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
В результате клиент умирает от удивления, со словами: "а мы так не договаривались"
...
Рейтинг: 0 / 0
25.10.2010, 22:14
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919114
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
Более того, точно такой же техникой на с++,
какой записывалось порождение квадратов из прямоугольников,
можно записать порождение прямоугольников из квадратов.
с точно той же проблемой не соответствия аксиом.
Эти классы не ребенок и родитель, а два близнеца.
Их не надо, вообще, один из другого порождать.
...
Рейтинг: 0 / 0
25.10.2010, 22:22
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919122
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
belugin
Участник
tchingiz,

как только ты делаешь квадрату setWidth он перестает быть квадратом. Надо просто в объектную модель ввести predicate classes как в языке cecil .
...
Рейтинг: 0 / 0
25.10.2010, 22:29
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919131
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
belugintchingiz,

как только ты делаешь квадрату setWidth он перестает быть квадратом. Надо просто в объектную модель ввести predicate classes как в языке cecil .

конечно, я это выше и продемонстрировал с примерами кода.
...
Рейтинг: 0 / 0
25.10.2010, 22:35
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919135
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
под словом квадрат я не имею ввиду ничего другого кроме как
объекты обсуждаемого класса Square.
Они заданы однозначно и совершенно понятно формальным описанием
на с++ в примера Роберта Мартина.
После вызова функций setWidth из своего класса, квадрат квадратом быть не перестает.
Это переменная, объявленная классом, возможно, оказавшаяся в противоречивом состоянии..
И обсуждается смысл техники программирования,
а не смысл геометрических фигур на плоскости.
...
Рейтинг: 0 / 0
25.10.2010, 22:39
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919143
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizпод словом квадрат я не имею ввиду ничего другого кроме как
объекты обсуждаемого класса Square.
Они заданы однозначно и совершенно понятно формальным описанием
на с++ в примера Роберта Мартина.

а чем тебе не понравилась моя реализация фигур?
...
Рейтинг: 0 / 0
25.10.2010, 22:52
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919166
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
а что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
...
Рейтинг: 0 / 0
25.10.2010, 23:17
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919175
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizа что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
если игнорировать метод show, то да.
...
Рейтинг: 0 / 0
25.10.2010, 23:25
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919200
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
tchingiz,
Пока не прочитал статью Лисковой, не понятно было о чем вы говорите )

Теперь возвращаюсь к своему же предыдущему утверждению:
инварианты (аксиоматика) связана с наследованием, и обязательна к учитыванию при проектировании.
...
Рейтинг: 0 / 0
25.10.2010, 23:50
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919261
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
естественно
...
Рейтинг: 0 / 0
26.10.2010, 00:44
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919263
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
Статья не Лисков, а Мартина
...
Рейтинг: 0 / 0
26.10.2010, 00:45
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919279
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingizа что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
если игнорировать метод show, то да.
не понял, что да.
ты написал в функциональном стиле. Мне кажется, что это означает что цепочка
Код: plaintext
1.
2.
3.
4.
5.
z -некоторый кортеж
Square s = new Square( 5 );
Rectangle r = s;
r.method(z);
s = r;
должна быть изменена в


Код: plaintext
1.
2.
3.
4.
z -некоторый кортеж;
Square s = new Square( 5 );
Rectangle r = s;
s = r.method(z);

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

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

вот это главное,
Код: plaintext
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.
...
Рейтинг: 0 / 0
26.10.2010, 01:04
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919284
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizZyK_BotaNtchingizа что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
если игнорировать метод show, то да.
не понял, что да.

только метод show нарушает принцип Лисков.

tchingiz
ты написал в функциональном стиле. Мне кажется, что это означает что цепочка
Код: plaintext
1.
2.
3.
4.
5.
z -некоторый кортеж
Square s = new Square( 5 );
Rectangle r = s;
r.method(z);
s = r;
должна быть изменена в


Код: plaintext
1.
2.
3.
4.
z -некоторый кортеж;
Square s = new Square( 5 );
Rectangle r = s;
s = r.method(z);

здесь можно подробней? я не понял.


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

вот это главное,
Код: plaintext
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.
тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.
...
Рейтинг: 0 / 0
26.10.2010, 01:21
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919288
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingiz
вот это главное,
Код: plaintext
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.

Код: 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.
public class Rectangle {
	private double w,h;
	public Rectangle(double w, double h) {
		this.w = w;
		this.h = h;
	}
	public Rectangle setWidth(double newW) {
		return new Rectangle(newW, h);
	}
	public Rectangle setHeight(double newH) {
		return new Rectangle(w, newH);
	}
	public double getWidth() {
		return w;
	}
	public double getHeight() {
		return h;
	}
}



public class Square extends Rectangle {
	public Square(double side) {
		super(side, side);
	}
	public Square(Rectangle r) {
		this(r.getHeight());
	}
	public Square setSide(double newSide) {
		return new Square( newSide );
	}
	
}


public class Main {
	static void showRectangle(Rectangle r) {
		System.out.println("Rectangle("+r.getWidth()+","+r.getHeight()+")");
	}
	static void showSquare(Square s) {
		System.out.println("Square("+s.getWidth()+")");
	}
	
	public static void main(String[] args) {
		Square s = new Square( 5 );
		Rectangle r = s.setWidth( 10 );
		showRectangle(r);
		showSquare(new Square(r)); //явное преобразование вниз по иерархии
	}
}

вывод:

Код: plaintext
1.
2.
Rectangle( 10 . 0 , 5 . 0 )
Square( 5 . 0 )
...
Рейтинг: 0 / 0
26.10.2010, 01:28
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919300
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNegorychZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.SetWidth(  10  ); // опа!

перечитай исправленную версию:
Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.setSide(  10  ); // опа!
и что в исправленной версии мне запретит написать мой вариант, интересно? вполне, казалось бы легальный код, а получаю Exception там, где его быть не должно.

ZyK_BotaNчто мне не нравится в моем коде, дак это метод show.
я его написал, что-бы короче было. лучше было бы написать два метода
showSquare и showRectangleну же, сделай последний шаг, и увидь, что Square и Rectangle - это не родственники совсем! переходи на светлую сторону силы, Люк ;-))

PS а мы даже ещё не добрались до ромба )))
...
Рейтинг: 0 / 0
26.10.2010, 01:46
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919301
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNegorychZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.SetWidth(  10  ); // опа!

перечитай исправленную версию:
Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.setSide(  10  ); // опа!
и что в исправленной версии мне запретит написать мой вариант, интересно? вполне, казалось бы легальный код, а получаю Exception там, где его быть не должно.

как это не должно?
метод setWidth возвращает Прямоугольник, а в исправленной версии появился метод квадрата setSide, пользуйся на здоровья и никаких ошибок.
egorych
ZyK_BotaNчто мне не нравится в моем коде, дак это метод show.
я его написал, что-бы короче было. лучше было бы написать два метода
showSquare и showRectangleну же, сделай последний шаг, и увидь, что Square и Rectangle - это не родственники совсем! переходи на светлую сторону силы, Люк ;-))

PS а мы даже ещё не добрались до ромба )))
посмотри на 49-е сообщение. я там избавился от метода show, и теперь классы соответствуют принципу Лисков.
...
Рейтинг: 0 / 0
26.10.2010, 01:50
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919305
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
ZyK_BotaN

PS а мы даже ещё не добрались до ромба )))
посмотри на 49-е сообщение. я там избавился от метода show, и теперь классы соответствуют принципу Лисков.

для работы с ромбом придется избавиться от Java. в ней нет множественного наследования.
...
Рейтинг: 0 / 0
26.10.2010, 01:54
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919306
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaN
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
	public static void main(String[] args) {
		Square s = new Square( 5 );
		Rectangle r = s.setWidth( 10 );
		showRectangle(r);
		showSquare(new Square(r)); //явное преобразование вниз по иерархии
	}
блистательно! а теперь делаем:
Код: plaintext
1.
2.
Square s = new Square(  5  );
showRectangle( s );
showSquare( s.setWidth(  10  ) );
и, поскольку, оба класса у нас зачем-то родственники, получаем 2 неожиданных результата.
Предлагаю ещё один великолепный вариант окончательно запутать код:
Код: plaintext
showRectangle( Square( s.setWidth(  10  ) ) );
о! всё легально, всё компилируется, получается чушь )))
...
Рейтинг: 0 / 0
26.10.2010, 01:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919309
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNпосмотри на 49-е сообщение. я там избавился от метода show, и теперь классы соответствуют принципу Лисков.посмотри лучше ты: для изменения размеров у Square и у Rectangle свои методы, для отображения у Square и Rectangle свои методы, в чём суть наследования теперь, можешь сказать? )))
...
Рейтинг: 0 / 0
26.10.2010, 02:01
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919316
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych
showSquare( s.setWidth( 10 ) );[/src]и, поскольку, оба класса у нас зачем-то родственники,

а как это может работать, setWidth возвращает прямоугольник.

egorych
Предлагаю ещё один великолепный вариант окончательно запутать код:
Код: plaintext
showRectangle( Square( s.setWidth(  10  ) ) );
о! всё легально, всё компилируется, получается чушь )))
Привидение вниз по иерархии было введено по заявкам слушателей:
tchingiz
у тебя нет обратного преобразования.
А в примере Мартина оно неявно требуется, при в начальном обсуждении,
когда выполнялось статическое связывание.

вот это главное,
Код: plaintext
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.
это я и сделал, изменил ширину, при этом произошла потеря точности.
но тут претензии не ко мне, этот метод был написан для tchingiz.
...
Рейтинг: 0 / 0
26.10.2010, 02:20
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919318
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNпосмотри на 49-е сообщение. я там избавился от метода show, и теперь классы соответствуют принципу Лисков.посмотри лучше ты: для изменения размеров у Square и у Rectangle свои методы, для отображения у Square и Rectangle свои методы, в чём суть наследования теперь, можешь сказать? )))

в методы работающие с прямоугольником могут работать и с квадратом, возвращая абсолютно идентичный результат(принцип Лисков).
методы работающие с квадратом не могут работать с прямоугольником, что и подтверждает данное выражение:
Код: plaintext
showRectangle( Square( s.setWidth(  10  ) ) );
здесь происходит явное приведение с потерей точности.



а зачем еще наследование нужно?
...
Рейтинг: 0 / 0
26.10.2010, 02:23
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919335
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych
PS а мы даже ещё не добрались до ромба )))

Код: 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.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
#include "stdafx.h"
#include <iostream>
class Rhomb {
	double a, side;
public:
	Rhomb(int ia, double iside) {
		a = ia;
		side = iside;
	}
	Rhomb setSide(double newSide) {
		return Rhomb(a, newSide);
	}
	Rhomb setA(int newA) {
		return Rhomb(newA, side);
	}
	int getA() {
		return a;
	}
	double getSide() {
		return side;
	}
};

class Rectangle {
	double w,h;
public:
	Rectangle(double iw, double ih) {
		w = iw;
		h = ih;
	}
	Rectangle setWidth(double newW) {
		return Rectangle(newW, h);
	}
	Rectangle setHeight(double newH) {
		return Rectangle(w, newH);
	}
	double getWidth() {
		return w;
	}
	double getHeight() {
		return h;
	}
};
class Square: public Rectangle, public Rhomb {
public:	
	Square(double side) : Rectangle(side, side),
		Rhomb( 90 , side) {
		
	}
	Square(Rectangle r) : Rectangle(r.getHeight(),r.getHeight()),
		Rhomb( 90 , r.getHeight()) {

	}
	Square(Rhomb r) : Rectangle(r.getSide(),r.getSide()),
		Rhomb( 90 , r.getSide()) {

	}
	Square setSide(double newSide) {
		return Square( newSide );
	}
	
};
    void showRectangle(Rectangle r) {
		std::cout << "Rectangle(" << r.getWidth() << "," << r.getHeight() << ")" << std::endl;
	}
	void showSquare(Square s) {
		std::cout << "Square(" << s.getSide() << ")" << std::endl;
	}
	void showRhomb(Rhomb r) {
		std::cout << "Rhomb(" << r.getA() << "," << r.getSide() << ")" << std::endl;
	}
int _tmain(int argc, _TCHAR* argv[])
{
	Square s = Square( 5 );
	Rhomb rhomb = Rhomb( 23 ,  20 );
	showRhomb(rhomb);
	showRhomb(s);
	showRhomb(rhomb.setSide( 8 ));
	showRhomb(s.setSide( 9 ));
	showRhomb(s.setA( 45 ));
	showSquare(Square(rhomb));
	return  0 ;
}

выводит:
Код: plaintext
1.
2.
3.
4.
5.
Rhomb( 23 , 20 )
Rhomb( 90 , 5 )
Rhomb( 23 , 8 )
Rhomb( 90 , 9 )
Rhomb( 45 , 5 )
Square( 20 )
...
Рейтинг: 0 / 0
26.10.2010, 02:50
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919340
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaN
тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.
с потерей точности - да.
поэтому в жизни вещественные - целые ( целые - натуральне) есть,
а по принципу Лисков их нельзя преобразовать. Они - разные типы.
...
Рейтинг: 0 / 0
26.10.2010, 03:00
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919343
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizZyK_BotaN
тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.
с потерей точности - да.
поэтому в жизни вещественные - целые ( целые - натуральне) есть,
а по принципу Лисков их нельзя преобразовать. Они - разные типы.

авторПусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
где здесь про перобразование типов от родительского к дочернему?
...
Рейтинг: 0 / 0
26.10.2010, 03:03
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919345
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingiz
должна быть изменена в


Код: plaintext
1.
2.
3.
4.
z -некоторый кортеж;
Square s = new Square( 5 );
Rectangle r = s;
s = r.method(z);

здесь можно подробней? я не понял.
то, что получается после применения метода method надо класть в переменную описанную
классом ребенка.
В цепочке должно быть два преобразования

ребенок -> родитель,
изменение ребенка, под видом родителя ранее написанными программами
родитель -> ребенок
...
Рейтинг: 0 / 0
26.10.2010, 03:05
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919348
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingizZyK_BotaN
тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.
с потерей точности - да.
поэтому в жизни вещественные - целые ( целые - натуральне) есть,
а по принципу Лисков их нельзя преобразовать. Они - разные типы.

авторПусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
где здесь про перобразование типов от родительского к дочернему?
я тебе рассказывал, что оно неявно всплывает.
Оно всплывает у Мартина когда он рассматривает первый шаг -
после преобразования ребенка в родителя вызывает родительский метод.
Метод нарушает инвариант ребенка, что делает невозможным обратное преобразование в ребенка.
Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.
И вот это уже, приводит к тому, что портятся РАНЕЕ НАПИСАННЫЕ ПРОГРАММЫ.
Их писали в предположении аксиом родителя.
Дизайн по контракту выявляет эту не очевидную трудность -
подкласс - это не подтип. Нельзя подставлять переменные как Лисков хочет.
...
Рейтинг: 0 / 0
26.10.2010, 03:12
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919349
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizZyK_BotaN tchingiz
должна быть изменена в


Код: plaintext
1.
2.
3.
4.
z -некоторый кортеж;
Square s = new Square( 5 );
Rectangle r = s;
s = r.method(z);

здесь можно подробней? я не понял.
то, что получается после применения метода method надо класть в переменную описанную
классом ребенка.
В цепочке должно быть два преобразования

ребенок -> родитель,
изменение ребенка, под видом родителя ранее написанными программами
родитель -> ребенок
я допилил класс.
теперь можно это сделать так:
Код: plaintext
1.
2.
3.
4.
z -некоторый кортеж;
Square s = new Square( 5 );
Rectangle r = s;
s = new Square(r.method(z));
но, покажи мне, где требуется такое поведение в принципе лисков, что-бы результат метода объекта подтипа, возвращал объект подтипа, а не суперкласса. Можно сузить возвращаемый тип, но это не обязательно.
...
Рейтинг: 0 / 0
26.10.2010, 03:13
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919350
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizЖукБотан
где здесь про перобразование типов от родительского к дочернему?
я тебе рассказывал, что оно неявно всплывает.
Оно всплывает у Мартина когда он рассматривает первый шаг -
после преобразования ребенка в родителя вызывает родительский метод.
Метод нарушает инвариант ребенка, что делает невозможным обратное преобразование в ребенка.
Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.
И вот это уже, приводит к тому, что портятся РАНЕЕ НАПИСАННЫЕ ПРОГРАММЫ.
Их писали в предположении аксиом родителя.
Дизайн по контракту выявляет эту не очевидную трудность -
подкласс - это не подтип. Нельзя подставлять переменные как Лисков хочет.

в моем случае не портятся.
вот старый код, в котором не знают о подтипе:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
void showRectangle(Rectangle r) {
		std::cout << "Rectangle(" << r.getWidth() << "," << r.getHeight() << ")" << std::endl;
	}
	

    Rectangle foo(Rectangle r) {
		r = r.setHeight(r.getWidth()* 2 );
		return r.setWidth( 2 );
	}

вот код, где используется старый код с объектом нового типа:

Код: plaintext
1.
2.
3.
4.
5.
int _tmain(int argc, _TCHAR* argv[]){
	Square s = Square( 5 );
	showRectangle(foo(s));
	return  0 ;
}

результат:
Rectangle(2,10);

что здесь работает не так?

приведи мне отдельно старый код, а потом новый, где нарушается работа.
...
Рейтинг: 0 / 0
26.10.2010, 03:20
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919351
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingiz
Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.

посмотри на пример написанный на с++. там нет ни одного виртуального метода.
...
Рейтинг: 0 / 0
26.10.2010, 03:21
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919353
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
в принципе это не требуется,
это обычное требование к наследованию.
...
Рейтинг: 0 / 0
26.10.2010, 03:28
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919355
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingiz
Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.

посмотри на пример написанный на с++. там нет ни одного виртуального метода.
на какой пример?
...
Рейтинг: 0 / 0
26.10.2010, 03:29
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919356
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizв принципе это не требуется,
это обычное требование к наследованию.
ты про динамическое связывание?
для для поддержки принципа Лисков оно и не нужно.
оно нужно для нарушения этого принципа.

tchingiz
это обычное требование к наследованию.

где оно записано?
...
Рейтинг: 0 / 0
26.10.2010, 03:30
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919358
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizZyK_BotaNtchingiz
Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.

посмотри на пример написанный на с++. там нет ни одного виртуального метода.
на какой пример?

http://sql.ru/forum/actualthread.aspx?tid=800476&pg=3#9674182
...
Рейтинг: 0 / 0
26.10.2010, 03:33
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919359
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
авторгде оно записано?
тебе целую главу вытащить?
щас посмотрю.
в принципе лисков написано для любой ранее написанной программы (квантор всеобщности),
а не для конкретной.
Если ты хочешь доказать, что нет таких программ, которые зависнут, то надо их все перебрать.
щас посмотрю
...
Рейтинг: 0 / 0
26.10.2010, 03:37
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919362
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizавторгде оно записано?
тебе целую главу вытащить?
щас посмотрю.
в принципе лисков написано для любой ранее написанной программы (квантор всеобщности),
а не для конкретной.
Если ты хочешь доказать, что нет таких программ, которые зависнут, то надо их все перебрать.
щас посмотрю

зачем все.
ты мне дай 1 пример старой программы работающей с Прямоугольником, поведение которой измениться при передаче ей квадрата.
...
Рейтинг: 0 / 0
26.10.2010, 03:39
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919363
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingiz
Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.

посмотри на пример написанный на с++. там нет ни одного виртуального метода.
посмотрел.
Ты находишься на шаге 1, после применения метода нельзя выполнить обратное
преобразование в квадрат.
и?
...
Рейтинг: 0 / 0
26.10.2010, 03:44
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919364
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingiz
посмотри на пример написанный на с++. там нет ни одного виртуального метода.
посмотрел.
Ты находишься на шаге 1, после применения метода нельзя выполнить обратное
преобразование в квадрат.
и?[/quot]

дак старый код не знает о существовании квадрата. (там только ромбы и прямоугольники )
как поломается код?
...
Рейтинг: 0 / 0
26.10.2010, 03:47
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919365
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
...
Рейтинг: 0 / 0
26.10.2010, 03:49
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919366
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingiz,

но в моем ведь коде этой проблемы нет.
...
Рейтинг: 0 / 0
26.10.2010, 03:51
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919367
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
вот так он поломался. Не код, а объект.
Был квадрат, а стороны стали разными.
теперь его нельзя назад преобразовать.
Почему Мартину это ясно, я не знаю. Это мистический ооп туман.
Если назад пробразовывать не надо - нет проблем.
...
Рейтинг: 0 / 0
26.10.2010, 03:51
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919368
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingiz,

но в моем ведь коде этой проблемы нет.
из за этого
Код: plaintext
1.
	showSquare(Square(rhomb));
?
так это явное преобразование любого кого попало в квадрат
...
Рейтинг: 0 / 0
26.10.2010, 03:54
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919370
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizвот так он поломался. Не код, а объект.
Был квадрат, а стороны стали разными.
теперь его нельзя назад преобразовать.
Почему Мартину это ясно, я не знаю. Это мистический ооп туман.
Если назад пробразовывать не надо - нет проблем.

у меня ничего не ломается.
потому, что я использую неизменяемые объекты.

пускай и Мартин их узает и не парит себе башку.

а если использовать изменяемые объекты и/или виртуальные методы, то принцип лисков будет нарушен.
...
Рейтинг: 0 / 0
26.10.2010, 03:55
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919371
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizZyK_BotaNtchingiz,

но в моем ведь коде этой проблемы нет.
из за этого
Код: plaintext
1.
	showSquare(Square(rhomb));
?
так это явное преобразование любого кого попало в квадрат

это не старый код.
этот код новый, ведь мы уже знаем о типе Square и явно к нему приводим.
я добавил приведение только потому, что ты попросил.
можно удалить этот конструктор, и избавиться от проблемы.
...
Рейтинг: 0 / 0
26.10.2010, 03:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919373
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
у тебя не ломается, потому что ты используешь явное преобразование.
Поэтому принцип Лисков и нафиг не нужен вообще.
можно строку в квадрат преобразовать.
...
Рейтинг: 0 / 0
26.10.2010, 03:57
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919376
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizу тебя не ломается, потому что ты используешь явное преобразование.
Поэтому принцип Лисков и нафиг не нужен вообще.
можно строку в квадрат преобразовать.
если удалить этот конструктор, принцип нарушаться будет?
...
Рейтинг: 0 / 0
26.10.2010, 03:58
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919377
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
пользователь может написать:

Код: plaintext
1.
showSquare(Square(rhomb.getSide()));
и ничего не ломается, мы явно игнорируем угол.
...
Рейтинг: 0 / 0
26.10.2010, 04:03
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919383
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
вот тут надо писать
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
int _tmain(int argc, _TCHAR* argv[])

{
	Square s = Square( 5 );
///	showRectangle(foo(s)); не это 
	showSquarе(foo(s)); а это
	return  0 ;
}

у тебя foo выдает родителя, которого нельзя приводить к ребенку

Код: plaintext
1.
2.
3.
void showSquare(Square s) {
		std::cout << "Square(" << s.getSide() << ")" << std::endl;
	}

правильно?
...
Рейтинг: 0 / 0
26.10.2010, 04:16
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919385
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNпользователь может написать:

Код: plaintext
1.
showSquare(Square(rhomb.getSide()));
и ничего не ломается, мы явно игнорируем угол.

а это типа еще короче? чем?
Код: plaintext
1.
showSquare(Square(rhomb));
...
Рейтинг: 0 / 0
26.10.2010, 04:19
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919386
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
вот эти твои комбинации называны в шаго 0 анафемой програмирования.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
    void showRectangle(Rectangle r) {
		std::cout << "Rectangle(" << r.getWidth() << "," << r.getHeight() << ")" << std::endl;
	}
	void showSquare(Square s) {
		std::cout << "Square(" << s.getSide() << ")" << std::endl;
	}
	void showRhomb(Rhomb r) {
		std::cout << "Rhomb(" << r.getA() << "," << r.getSide() << ")" << std::endl;
	}
...
Рейтинг: 0 / 0
26.10.2010, 04:22
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919569
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN,

У тебя нет клиента, полагающегося на аксиоматику базового класса. Потому и не ломается - нечему )))
Заведи в базовом классе ф-цию расчета площади (Она будет клиентом). Без ее явного переписывания (override) в наследниках работать будет неверно.
Вариант 2 предъявления проблемы. Возьми сторонний класс, который получает фигуры, например коллекцию. И напиши функцию суммирования площади хранимых объектов.

Если соблюсти DbC, то при работе программы правильно сформулированный инвариант родителя обломится, и ты узнаешь о проблеме.
...
Рейтинг: 0 / 0
26.10.2010, 09:34
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919584
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN> class Square: public Rectangle, public Rhomb

странное наследование. Чего хотим получить, козловерблюда?
...
Рейтинг: 0 / 0
26.10.2010, 09:40
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919593
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNметоды работающие с прямоугольником могут работать и с квадратом, возвращая абсолютно идентичный результат(принцип Лисков).это не правда, точнее, не вся правда. Правдой будет написать, что "методы, работающие с прямоугольником, будут скомпилированы и с квадратом, возвращая абсолютно непредсказуемый вариант". В пояснение простой пример: есть функция, которая вписывает произвольный прямоугольник в заданный и возвращает полученный прямоугольник. Я хочу ей воспользоваться, чтобы в заданный прямоугольник вписать квадрат, а потом дальше использовать его, как квадрат. Для пары Rectangle( 10, 2 ) + Square( 5 ) я получу правильный ответ, для пары Rectangle( 2, 10 ) + Square( 5 ) - неправильный.
...
Рейтинг: 0 / 0
26.10.2010, 09:45
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36919619
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
SiemarglZyK_BotaN,

У тебя нет клиента, полагающегося на аксиоматику базового класса.у него нет ни одной проверки инвариантов ни для прямоугольника, ни для квадрата.
Хотим изменить сторону у квадрата, воспользовавшись функцией базового класса - "бам!" - на тебе произвольный прямоугольник, хотим сделать квадрат из прямоугольника 3х4 - "бам!" - на тебе квадрат 4х4! почему именно такой, почему не 3х3? - потому что гладиолус! какие уж тут "контракты" )))
...
Рейтинг: 0 / 0
26.10.2010, 09:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920061
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingiz оказалось невозможное корректное выполнение цепочка
а) преобразование из ребенка в родителя
б) выполнение метода
в) восстановление ребенка взад.

А зачем делать а), если можно сразу сделать б) и не делать с)
Другое дело, что выполнение б) может нарушить инвариант ребенка и вызовет ошибку, так это нормальное поведение, так и д.б. Похоже, проблемы то и нет.
...
Рейтинг: 0 / 0
26.10.2010, 12:20
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920071
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingiz(класс это пара (множество_допустимых_значений, множество_функций),
множество_допустимых_значений - это тип данных, а вот множество_функций - очень расплывчато. Я могу написать очень много функций, использующих этот тип данных в качестве парметров или значений, не включая их в класс. И что это будет ? Итак мы плавно возвращаемся к модульности в терминах АДы.
...
Рейтинг: 0 / 0
26.10.2010, 12:26
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920089
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingizвот аксиомы обоих классов
http://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=4#9543464
Просто для квадрата SetWidthe и SetHeight должны вызываться одновременно (как один оператор или транзакция) и с одной и то же величиной, чтобы не разрушить квадрат.
Код: plaintext
1.
2.
begin sq.SetWidthe( 10 ),sq.SetHeight( 10 ) end
begin sq.SetWidthe( 5 ),sq.SetHeight( 10 ) end  - а это ошибка
...
Рейтинг: 0 / 0
26.10.2010, 12:32
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920100
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingizПотом ты пишешь ребенка, херишь аксиомы родителя, и подсовываешь тем
программам, которые написаны в предположении похереных аксиом
ребенка под видом родителя.
В результате клиент умирает от удивления. Нарушен принцип подстановки Лисков.

аксиомы родителя полностью сохраняются, только дополняются аксиомами ребенка.
попытки применить методы родителя к ребенку никакого удивления вызывать не должны - ошибки ожидаемы и запрограммированы.
...
Рейтинг: 0 / 0
26.10.2010, 12:37
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920164
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizвот тут надо писать
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
int _tmain(int argc, _TCHAR* argv[])

{
	Square s = Square( 5 );
///	showRectangle(foo(s)); не это 
	showSquarе(foo(s)); а это
	return  0 ;
}

у тебя foo выдает родителя, которого нельзя приводить к ребенку

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


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

tchingiz
Код: plaintext
1.
2.
3.
void showSquare(Square s) {
		std::cout << "Square(" << s.getSide() << ")" << std::endl;
	}

правильно?
да
...
Рейтинг: 0 / 0
26.10.2010, 13:00
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920171
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizZyK_BotaNпользователь может написать:

Код: plaintext
1.
showSquare(Square(rhomb.getSide()));
и ничего не ломается, мы явно игнорируем угол.

а это типа еще короче? чем?
Код: plaintext
1.
showSquare(Square(rhomb));

нет, просто можно обойтись и без приведения типов.
во втором случае нет неоднозначностей, мы явно игнорируем угол ромба.
в первом случае, перерасчет сторон квадрата не однозначен, ведь ф-я приведения может быть реализована по разному(например сохранять площадь фигуры).
...
Рейтинг: 0 / 0
26.10.2010, 13:02
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920179
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizвот эти твои комбинации называны в шаго 0 анафемой програмирования.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
    void showRectangle(Rectangle r) {
		std::cout << "Rectangle(" << r.getWidth() << "," << r.getHeight() << ")" << std::endl;
	}
	void showSquare(Square s) {
		std::cout << "Square(" << s.getSide() << ")" << std::endl;
	}
	void showRhomb(Rhomb r) {
		std::cout << "Rhomb(" << r.getA() << "," << r.getSide() << ")" << std::endl;
	}


мы говорим о принципе Лисков?
значит этот принцип предан анафеме
как может выполняться принцип Лисков, если мы будем использовать виртуальные ф-и?
...
Рейтинг: 0 / 0
26.10.2010, 13:04
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920215
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,

У тебя нет клиента, полагающегося на аксиоматику базового класса. Потому и не ломается - нечему )))
Заведи в базовом классе ф-цию расчета площади (Она будет клиентом). Без ее явного переписывания (override) в наследниках работать будет неверно.
Вариант 2 предъявления проблемы. Возьми сторонний класс, который получает фигуры, например коллекцию. И напиши функцию суммирования площади хранимых объектов.

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

перерасчет будет работать верно,

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
double sumOfSpace(std::vector<Rectangle> rs) {
		double sum =  0 ;
		for (std::vector<Rectangle>::iterator i = rs.begin(); i != rs.end(); ++i) {
			sum += (*i).getSpace();
		}
		return sum;
	}
int _tmain(int argc, _TCHAR* argv[])
{
	std::vector<Rectangle> v;
	v.push_back(Rectangle( 5 ,  4 ));
	v.push_back(Square( 3 ));
	v.push_back(Square( 2 ));
	std::cout << sumOfSpace(v) << std::endl;
	return  0 ;
}
вывод : 33.
что я делаю не так?
...
Рейтинг: 0 / 0
26.10.2010, 13:17
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920222
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych[quot Siemargl]ZyK_BotaN,

Хотим изменить сторону у квадрата, воспользовавшись функцией базового класса - "бам!" - на тебе произвольный прямоугольник

где?
у базового класса(Rectangle) нет ф-и изменения стороны, есть только изменение ширины или высоты.

у базового класса Rhomb - есть ф-я изменения стороны и она работает коректно, гарантировано возвращая квадрат(так как угол тоно не измениться).
...
Рейтинг: 0 / 0
26.10.2010, 13:20
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920278
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN
вывод : 33.
что я делаю не так?
Ты код то покажи. Полный, где getSpace() описан.
...
Рейтинг: 0 / 0
26.10.2010, 13:40
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920760
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNegorych[quot Siemargl]ZyK_BotaN,

Хотим изменить сторону у квадрата, воспользовавшись функцией базового класса - "бам!" - на тебе произвольный прямоугольникгде?
у базового класса(Rectangle) нет ф-и изменения стороны, есть только изменение ширины или высоты.0. про ромб пока забудем опять, говорим за прямоугольник.

1. теперь по буквам:
- мы говорим: квадрат - это прямоугольник ( отнаследовали квадрат от прямоугольника ).
- у прямоугольника есть ширина и высота ( аксиома прямоугольника ),
- у квадрата есть ширина и высота ( аксиома наследования ).
- у квадрата ширина и высота совпадают ( аксиома квадрата ).
- изменяя ширину ( или высоту ) я надеюсь получить квадрат ( принцип наименьшего удивления ), пусть приведённый к типу родителя ( требование языка ).
Но! либо я получаю прямоугольник и по типу, и по содержанию, что противоречит аксиоме квадрата. Или я получаю квадрат ( переопределив сеттеры в наследнике ) и нарушаю аксиомы прямоугольника. Но противоречий ты технично не замечаешь.

2. по остальным пунктам обвинения сказать определённо нечего, ась? ;-))
...
Рейтинг: 0 / 0
26.10.2010, 16:08
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36920769
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
SiemarglZyK_BotaN
вывод : 33.
что я делаю не так?
Ты код то покажи. Полный, где getSpace() описан.да не, площади-то у прямоугольника и квадрата вычисляются одинаково ( width*height ), этот пример будет работать корректно, все косяки связаны с размерами.
...
Рейтинг: 0 / 0
26.10.2010, 16:11
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921145
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN
вывод : 33.
что я делаю не так?
Ты код то покажи. Полный, где getSpace() описан.

ага, забыл

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
class Rhomb {
	double a, side;
public:
	double getSpace() {
		return sin(a)*side*side;
	}
};

class Rectangle {
	double w,h;
public:
	
	double getSpace() {
		return w*h;
	}
};
class Square: public Rectangle, public Rhomb {
public:	
	
	
};
...
Рейтинг: 0 / 0
26.10.2010, 18:23
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921162
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNegorych[quot Siemargl]ZyK_BotaN,

Хотим изменить сторону у квадрата, воспользовавшись функцией базового класса - "бам!" - на тебе произвольный прямоугольникгде?
у базового класса(Rectangle) нет ф-и изменения стороны, есть только изменение ширины или высоты.0. про ромб пока забудем опять, говорим за прямоугольник.


- изменяя ширину ( или высоту ) я надеюсь получить квадрат ( принцип наименьшего удивления )

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


egorych
, пусть приведённый к типу родителя ( требование языка ).
Но! либо я получаю прямоугольник и по типу, и по содержанию, что противоречит аксиоме
квадрата.
какой аксиоме?

egorych
Или я получаю квадрат ( переопределив сеттеры в наследнике ) и нарушаю аксиомы прямоугольника. Но противоречий ты технично не замечаешь.

не делай так.
egorych
2. по остальным пунктам обвинения сказать определённо нечего, ась? ;-))
я не понимаю, почему изменяя только ширину квадрата, Вы хотите получить квадрат.
меня бы такое поведение удивило бы.

подтверждением моей точки зрения является вечная ошибка новичков, которые не знают что 2/3 = 0.

а в паскале все ок. 1/2 = 0.5 и я с господином Виртом согласен.
...
Рейтинг: 0 / 0
26.10.2010, 18:30
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921165
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychSiemarglZyK_BotaN
вывод : 33.
что я делаю не так?
Ты код то покажи. Полный, где getSpace() описан.да не, площади-то у прямоугольника и квадрата вычисляются одинаково ( width*height ), этот пример будет работать корректно, все косяки связаны с размерами.

и я о том же. если сделать объекты фигур неизменяемые(частая практика: примитивные типы, строки) и не использовать виртуальных методов(они тогда не нунжны), то принцип Лисков нарушаться не будет.
...
Рейтинг: 0 / 0
26.10.2010, 18:32
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921231
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN,

Ты чего то опять забыл. У тебя в Square неоднозначность вызова getSpace().
...
Рейтинг: 0 / 0
26.10.2010, 18:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921263
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,

Ты чего то опять забыл. У тебя в Square неоднозначность вызова getSpace().

все ок, неоднозначность решается клиентом,
Код: plaintext
Square( 3 ).Rectangle::getSpace()
но можно и исправить
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
class Square: public Rectangle, public Rhomb {
public:	
	
	double getSpace() {
		return Rectangle::getSpace();
	}
	
};

но это уже не обязательно. явное указание родителя, которому принадлежит метод - нормальная практика.

например ее используют в языке F#.
...
Рейтинг: 0 / 0
26.10.2010, 19:02
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921298
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,

Ты чего то опять забыл. У тебя в Square неоднозначность вызова getSpace().

а ошибка у меня там математическая(в случае с ромбом), угол у меня храниться в градусах, а синус наверное ожидает радианы, но нашей дискуссии это не касается.
...
Рейтинг: 0 / 0
26.10.2010, 19:15
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921413
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
начнём с конца

ZyK_BotaNя не понимаю, почему изменяя только ширину квадрата, Вы хотите получить квадрат.
меня бы такое поведение удивило бы.потому что я хочу писать правильные, корректно работающие, понятные и легко сопровождаемые программы без излишнего оверхеда на ровном месте.
Если я работаю только в рамках типа "квадрат", или "int", то я всегда хочу в этих рамках оставаться, и не испытывать проблем с чехардой типов. Целочисленное деление 1 на 2 должно мне возвращать 0, функция класса "квадрат" с говорящим названием SetWidth() должна возвращать мне "квадрат", а ещё лучше менять текущий объект и, может быть, возвращать ссылку на него. Назови её GetRectangleWithNewWidth() и мои претензии сразу пропадут.
Динамическая смена типов приводит к усложнению программы, а как следствие - к трудноуловимым плохо локализуемым ошибкам.
ZyK_BotaNподтверждением моей точки зрения является вечная ошибка новичков, которые не знают что 2/3 = 0.
а в паскале все ок. 1/2 = 0.5 и я с господином Виртом согласен.Ну а я - нет ( правда удивительно?:)) )Проблемы новичков меня заботят мало, если им везде подстилать соломку, то они так и останутся новичками, а мне бы хотелось, чтобы профессионалов и знатоков в программировании становилось больше, их и так не хватает катастрофически.
Заодно вспомним, что паскаль создавался именно как _учебный_ язык программирования. И тот факт, что он стал применяться ( и успешно ) в промышленных разработках, этого не отменяет.

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

>> есть метод setSide, его и юзай.
я всё ещё жду комментария на этот вот простой пример.

и ещё хочется услышать ответ на этот простой вопрос
egorychхотим сделать квадрат из прямоугольника 3х4 - "бам!" - на тебе квадрат 4х4! почему именно такой, почему не 3х3?на основании какой из аксиом квадрата, прямоугольника, или, не дай бог, ромба, следует, что квадрат конструируется из высоты прямоугольника?
...
Рейтинг: 0 / 0
26.10.2010, 20:29
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921414
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
_модtchingiz оказалось невозможное корректное выполнение цепочка
а) преобразование из ребенка в родителя
б) выполнение метода
в) восстановление ребенка взад.

А зачем делать а), если можно сразу сделать б) и не делать с)
Другое дело, что выполнение б) может нарушить инвариант ребенка и вызовет ошибку, так это нормальное поведение, так и д.б. Похоже, проблемы то и нет.
а нужно сделать, чтобы передать ребенка в ранее написанные программы
для родителя
...
Рейтинг: 0 / 0
26.10.2010, 20:29
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921420
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaN,
что ты делаешь с цитатами вечно?
задолбался править тебя.
сложи в зип весь код и прилепи сюда, а то не возможно бегать по постам
.
а нельзя его упростить, кстати. Хватит одного наследования для иллюстрации замечательной
мысли про неизменяемые объекты.
Лучше квадрат и прямоугольник оставить - меньше работать придется
...
Рейтинг: 0 / 0
26.10.2010, 20:33
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921422
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
tchingizа нельзя его упростить, кстати. Хватит одного наследования для иллюстрации замечательной мысли про неизменяемые объекты.
Лучше квадрат и прямоугольник оставить - меньше работать придется+1
...
Рейтинг: 0 / 0
26.10.2010, 20:35
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921428
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
_модtchingizПотом ты пишешь ребенка, херишь аксиомы родителя, и подсовываешь тем
программам, которые написаны в предположении похереных аксиом
ребенка под видом родителя.
В результате клиент умирает от удивления. Нарушен принцип подстановки Лисков.

аксиомы родителя полностью сохраняются, только дополняются аксиомами ребенка.
попытки применить методы родителя к ребенку никакого удивления вызывать не должны - ошибки ожидаемы и запрограммированы.
если при наследовании происходит уменьшение домена типа
например, как от вещественных к целым, или от целых к натуральным,
а меньшее множество обладает свойством идеала относительно операции,
скажем f : X >< X -> X, (где X домен родителя.
а Y домен ребенка, Y входит в X)
то есть, для любого x из X и y из Y f (y, x) попадает в Y,
то можно вызывать методы родителя сколько угодно.
...
Рейтинг: 0 / 0
26.10.2010, 20:39
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921439
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
_модtchingiz(класс это пара (множество_допустимых_значений, множество_функций),
множество_допустимых_значений - это тип данных, а вот множество_функций - очень расплывчато. Я могу написать очень много функций, использующих этот тип данных в качестве парметров или значений, не включая их в класс. И что это будет ? Итак мы плавно возвращаемся к модульности в терминах АДы.
я с твоего позволения буду называть множество_допустимых_значений
доменом типа, ибо тип - это спецификация класса, то есть, набор аксиом.

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

Среди множества всех написанных функций, желательно выделить
подмножество таких, которые нельзя написать через другие, и их то и вносить
в класс. Судьба остальных зависит от произвола проектировщика
...
Рейтинг: 0 / 0
26.10.2010, 20:45
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921448
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
egorychна основании какой из аксиом квадрата, прямоугольника, или, не дай бог, ромба, следует, что квадрат конструируется из высоты прямоугольника?
а че не из площади или диагонали?
))
кста, если добавить аксиому к тем четырем, то это будет новый тип Square,
а не тот, с которого все началось.
...
Рейтинг: 0 / 0
26.10.2010, 20:50
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921551
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaNSiemarglZyK_BotaN,

Ты чего то опять забыл. У тебя в Square неоднозначность вызова getSpace().

все ок, неоднозначность решается клиентом,
Код: plaintext
Square( 3 ).Rectangle::getSpace()
но можно и исправить
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
class Square: public Rectangle, public Rhomb {
public:	
	
	double getSpace() {
		return Rectangle::getSpace();
	}
	
};

но это уже не обязательно. явное указание родителя, которому принадлежит метод - нормальная практика.

например ее используют в языке F#.
Знаешь, такой стиль программирования побуждает меня тебя придушить.

Но это наверное, уже оффтоп, не относящийся к правильному и тем более контрактному програмировнию ))))
...
Рейтинг: 0 / 0
26.10.2010, 22:25
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921686
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychначнём с конца

ZyK_BotaNя не понимаю, почему изменяя только ширину квадрата, Вы хотите получить квадрат.
меня бы такое поведение удивило бы.потому что я хочу писать правильные, корректно работающие, понятные и легко сопровождаемые программы без излишнего оверхеда на ровном месте.
Если я работаю только в рамках типа "квадрат", или "int"

ну и используйте в случае квадрата setSide, а в случае int-а div.

egorych
Целочисленное деление 1 на 2 должно мне возвращать 0, функция класса "квадрат" с говорящим названием SetWidth() должна возвращать мне "квадрат"

вот именно что "целочисленное деление", а не обычное. вот и юзайте div.
с квадратом то же самое, зачем себе придумывать проблемы, мы ведь знаем, что если setWidth будет изменять высоту, то у нас появятся проблемы. дак зачем нам эти проблемы?


egorych
а ещё лучше менять текущий объект и, может быть, возвращать ссылку на него. Назови её GetRectangleWithNewWidth() и мои претензии сразу пропадут.

Динамическая смена типов приводит к усложнению программы, а как следствие - к трудноуловимым плохо локализуемым ошибкам.


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

egorych

Проблемы новичков меня заботят мало, если им везде подстилать соломку, то они так и останутся новичками, а мне бы хотелось, чтобы профессионалов и знатоков в программировании становилось больше, их и так не хватает катастрофически.

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


egorychхотим сделать квадрат из прямоугольника 3х4 - "бам!" - на тебе квадрат 4х4! почему именно такой, почему не 3х3?
здесь я с вами абсолютно согласен:
/topic/800476&pg=4#9674234
...
Рейтинг: 0 / 0
27.10.2010, 00:36
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921691
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNметоды работающие с прямоугольником могут работать и с квадратом, возвращая абсолютно идентичный результат(принцип Лисков).это не правда, точнее, не вся правда. Правдой будет написать, что "методы, работающие с прямоугольником, будут скомпилированы и с квадратом, возвращая абсолютно непредсказуемый вариант". В пояснение простой пример: есть функция, которая вписывает произвольный прямоугольник в заданный и возвращает полученный прямоугольник. Я хочу ей воспользоваться, чтобы в заданный прямоугольник вписать квадрат, а потом дальше использовать его, как квадрат. Для пары Rectangle( 10, 2 ) + Square( 5 ) я получу правильный ответ, для пары Rectangle( 2, 10 ) + Square( 5 ) - неправильный.

можете метод хотябы на псевдокоде написать? а то я суть не понял.

egorych
а потом дальше использовать его, как квадрат.

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

вас не смущает что sin(1) - не целое? здесь аналогично.
вы понимаете что такое подтип? и что объект типа, не всегда можно без потери точности привести к подтипу?
...
Рейтинг: 0 / 0
27.10.2010, 00:42
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921694
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychtchingizа нельзя его упростить, кстати. Хватит одного наследования для иллюстрации замечательной мысли про неизменяемые объекты.
Лучше квадрат и прямоугольник оставить - меньше работать придется+1
что +1? а кто мне про ромб напомнил?
хорошо, ромб удалю.
...
Рейтинг: 0 / 0
27.10.2010, 00:44
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921697
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
Siemargl

Знаешь, такой стиль программирования побуждает меня тебя придушить.

Но это наверное, уже оффтоп, не относящийся к правильному и тем более контрактному програмировнию ))))

а можно конкретней. покажи мне исправленный код?
что плохого в том, что явно задается имя класса где реализован метод?
...
Рейтинг: 0 / 0
27.10.2010, 00:47
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921701
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizБолее того, точно такой же техникой на с++,
какой записывалось порождение квадратов из прямоугольников,
можно записать порождение прямоугольников из квадратов.

нет, тогда код будет работать не корректно.
...
Рейтинг: 0 / 0
27.10.2010, 00:50
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921705
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizegorychна основании какой из аксиом квадрата, прямоугольника, или, не дай бог, ромба, следует, что квадрат конструируется из высоты прямоугольника?
а че не из площади или диагонали?
))
кста, если добавить аксиому к тем четырем, то это будет новый тип Square,
а не тот, с которого все началось.
не из площади ли диагонали потому, что это метод заказал ты, явно указал что нужно инорить ширину:

tchingiz
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.

а мне это метод нафиг не надо. хорошо, выпилю.
...
Рейтинг: 0 / 0
27.10.2010, 00:52
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921714
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNegorychа потом дальше использовать его, как квадрат.в этом ваша проблема.
вы хотите использовать результат ф-и работающей с прямоугольником в качестве квадратанеа, это твоя проблема, потому что ты используешь наследование там, где оно противоречит всему, кроме одного утверждения: квадрат - это частный случай прямоугольника. Чтобы доказать обратное ты создал такое количество ограничений, что пользоваться иерархией и не породить ошибку стало практически не возможно. Пришлось даже отказаться от использования виртуальных методов и изменяющих методов класса, и, чтобы это не выглядело совсем глупонепрезентабельно, рассказываешь истории про пользу функционального стиля программирования и занимаешься софистикой.
...
Рейтинг: 0 / 0
27.10.2010, 01:10
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921720
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNegorychа потом дальше использовать его, как квадрат.в этом ваша проблема.
вы хотите использовать результат ф-и работающей с прямоугольником в качестве квадратанеа, это твоя проблема, потому что ты используешь наследование там, где оно противоречит всему, кроме одного утверждения: квадрат - это частный случай прямоугольника. Чтобы доказать обратное ты создал такое количество ограничений, что пользоваться иерархией и не породить ошибку стало практически не возможно. Пришлось даже отказаться от использования виртуальных методов и изменяющих методов класса, и, чтобы это не выглядело совсем глупонепрезентабельно, рассказываешь истории про пользу функционального стиля программирования и занимаешься софистикой.

ты часто пользуешься такими объектами как : int, double, string?
ихнее поведение не отличается от моего.

вот пример иерархии типов хаскелла, в подтверждение что не только я считаю Целые подтипом Вещественных:
...
Рейтинг: 0 / 0
27.10.2010, 01:22
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921722
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
ZyK_BotaN
ты часто пользуешься такими объектами как : int, double, string?
ихнее поведение не отличается от моего.

я здесь имел ввиду иммутабельность и отсутствие виртуальных методов.
...
Рейтинг: 0 / 0
27.10.2010, 01:24
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921725
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaN:
>> ну и используйте в случае квадрата setSide,
допустим, у меня есть легаси-код, работающий с прямоугольниками и, раз квадрат - наследник его, то я хочу, чтобы он работал с квадратами. Корректно работал. Обычно у меня это получается, если иерархия наследования составлена верно. и не получается, когда приходится помнить "здесь читать, здесь не читать, здесь рыбу заворачивать".
>> а в случае int-а div.
сами вы используйте свой div, мне инта вполне достаточно. Если в паскале нужен дополнительный "совсем целочисленный" тип, то это его проблема. У меня в С++ всё работает, как надо.

>> вот именно что "целочисленное деление", а не обычное. вот и юзайте div.
>> с квадратом то же самое, зачем себе придумывать проблемы, мы ведь знаем, что если setWidth
>> будет изменять высоту, то у нас появятся проблемы. дак зачем нам эти проблемы?
у нас возникают проблемы, потому что есть неразрешимое противоречие аксиом двух классов: прямоугольника и квадрата, других проблем не диагностируется


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

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

ZyK_BotaNegorychхотим сделать квадрат из прямоугольника 3х4 - "бам!" - на тебе квадрат 4х4! почему именно такой, почему не 3х3?
здесь я с вами абсолютно согласен:
/topic/800476&pg=4#9674234с чем согласен? это ведь ты этот метод породил, чтобы соблюсти формальное условие, наплевав на семантику обоих классов. И нечего на Чингиза пенять :))
Код: plaintext
Square( const Rectangle &parent )\n{\n   if( parent.getWidth() != parent.getHeight() )\n      throw exception( "I can\'t construct Square from this Rectangle. sorry!" );\n\n   _width = _height = parent.getWidth();\n}
тоже не идеал
...
Рейтинг: 0 / 0
27.10.2010, 01:33
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921730
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaN:
>> ну и используйте в случае квадрата setSide,
допустим, у меня есть легаси-код, работающий с прямоугольниками и, раз квадрат - наследник его, то я хочу, чтобы он работал с квадратами. Корректно работал. Обычно у меня это получается, если иерархия наследования составлена верно. и не получается, когда приходится помнить "здесь читать, здесь не читать, здесь рыбу заворачивать".
>> а в случае int-а div.
сами вы используйте свой div, мне инта вполне достаточно. Если в паскале нужен дополнительный "совсем целочисленный" тип, то это его проблема. У меня в С++ всё работает, как надо.


старый код будет работать с квадратом врено. я гарантирую это.

div - это не тип, а операция целочисленного деления.


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

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

egorych
согласен? это ведь ты этот метод породил, чтобы соблюсти формальное условие,

нет. я не видел такого формального условия в описании принципа подстановки Лисков.

egorych

Код: plaintext
1.
2.
3.
4.
5.
6.
Square( const Rectangle &parent )
{
   if( parent.getWidth() != parent.getHeight() )
      throw exception( "I can't construct Square from this Rectangle. sorry!" );

   _width = _height = parent.getWidth();
}
тоже не идеал
этот код, не только не идиал, но в отличии от моего порождает ошибку и не соответствует принципу подстановки Лисков.
...
Рейтинг: 0 / 0
27.10.2010, 01:41
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921733
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNты часто пользуешься такими объектами как : int, double, string?
ихнее поведение не отличается от моего.у меня этих стрингов, как собак не резанных, в плюсах-то и у каждого - своё поведение А в сях так вообще строки нет, как таковой.
и int и double не порождают других типов при операциях с подобными себе, и это сильно отличается от представленного тобой

ЗЫ каламбур получился, кстати ))
ЗЫЫ за хаскель комментировать не буду, может оно там действительно надо
...
Рейтинг: 0 / 0
27.10.2010, 01:43
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921734
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
ZyK_BotaNпроцитируйте код, где квадрат превращается в прямоугольник.

если быть точнее, где он перестает быть квадратом.
ведь прямоугольником он является всегда.
...
Рейтинг: 0 / 0
27.10.2010, 01:44
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921738
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych
и int и double не порождают других типов при операциях с подобными себе, и это сильно отличается от представленного тобой

ЗЫ каламбур получился, кстати ))
ЗЫЫ за хаскель комментировать не буду, может оно там действительно надо
ты наверное про си, а в паскале и в делфе, операция еделения определена надо вещественными типами.

как неявное преобразования int к double объяснить. наверное int все же должен быть подтипом double.

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

int, double и string я упомянул, что-бы оправдать иммутабельность.
...
Рейтинг: 0 / 0
27.10.2010, 01:49
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921741
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNстарый код будет работать с квадратом верно. я гарантирую это.зря подписался. Возвращаемся к примеру: Есть функция, обрабатывающая прямоугольники
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
вписать один прямоугольник в другой
параметры: base - прямоугольник, в который вписывают,
           changed - прямоугольник, который вписываем
возвращаемое значение: returned вписанный прямоугольник

 1 . если у changed ширина больше, чем у base - ширина returned = ширине base
 2 . если у changed высота больше, чем у base - высота returned = высоте base
 3 . возврат returned
вполне себе бессмысленная функция. Теперь я туда подаю следующие пары:
- base - Rectangle( 10, 2 ), changed = Square( 5 ) и получу правильный ответ
- base = Rectangle( 2, 10 ), changed = Square( 5 ) - неправильный.
кроме того, я получу хороший оверхед на том, что постоянно буду конструировать объекты вместо того, чтобы их изменять, но это вопрос уже из другой песни, оставим его пока
...
Рейтинг: 0 / 0
27.10.2010, 02:01
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921743
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNZyK_BotaNпроцитируйте код, где квадрат превращается в прямоугольник.

если быть точнее, где он перестает быть квадратом.
ведь прямоугольником он является всегда.да вот же:
Код: plaintext
1.
Square s = new Square(  5  );
Square except = s.SetWidth(  3  );// всё, это уже не квадрат

>> как неявное преобразования int к double объяснить. наверное int все же должен быть подтипом double.
1. никакого преобразования не происходит, если я выполняю операции в рамках одного типа.
2. как неявное преобразование double к int объяснить, наверное double всё же должен быть подтипом int ( самому не смешно? мне - смешно, например ))) )
3. эти неявные преобразования никакого отношения к наследованию не имеют

>> int, double и string я упомянул, что-бы оправдать иммутабельность.
тебе пришлось ввести иммутабельность, чтобы хоть как-то организовать наследование квадрата от прямоугольника, с изменяемыми объектами у тебя не выйдет ничего из этой затеи. Больше она низачем в данном случае, по крайней мере, не нужна. Это - факт! ))
...
Рейтинг: 0 / 0
27.10.2010, 02:09
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921744
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych
[/src]вполне себе бессмысленная функция. Теперь я туда подаю следующие пары:
- base - Rectangle( 10, 2 ), changed = Square( 5 ) и получу правильный ответ
- base = Rectangle( 2, 10 ), changed = Square( 5 ) - неправильный.
кроме того, я получу хороший оверхед на том, что постоянно буду конструировать объекты вместо того, чтобы их изменять, но это вопрос уже из другой песни, оставим его пока

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
	Rectangle f(Rectangle base, Rectangle changed) {
		return Rectangle((changed.getWidth()>base.getWidth()?base.getWidth():changed.getWidth()),
			(changed.getHeight()>base.getHeight()?base.getHeight():changed.getHeight()));
	}

int _tmain(int argc, _TCHAR* argv[])
{
	Rectangle r1 = f(Rectangle( 10 ,  2 ), Square( 5 ));
	Rectangle r2 = f(Rectangle( 2 ,  10 ), Square( 5 ));
	showRectangle(r1); 
	showRectangle(r2);
	return  0 ;
}

результат:
Rectangle(5,2);
Rectangle(2,5);
...
Рейтинг: 0 / 0
27.10.2010, 02:10
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921745
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNэтот код, не только не идиал, но в отличии от моего порождает ошибку и не соответствует принципу подстановки Лисков.зато он хотя бы пытается хоть как-то проверить соответствие входящих параметров контракту класса, а не лепит непойми что из непойми чего по дефолту.
...
Рейтинг: 0 / 0
27.10.2010, 02:15
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921746
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNZyK_BotaNпроцитируйте код, где квадрат превращается в прямоугольник.

если быть точнее, где он перестает быть квадратом.
ведь прямоугольником он является всегда.да вот же:
Код: plaintext
1.
Square s = new Square(  5  );
Square except = s.SetWidth(  3  );// всё, это уже не квадрат

это мой код?
он не скомпилится.

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

нет здесь динамической подмены квадрата прямоугольником, а вернее квадрат остался квадратом.
...
Рейтинг: 0 / 0
27.10.2010, 02:16
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921747
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNэтот код, не только не идиал, но в отличии от моего порождает ошибку и не соответствует принципу подстановки Лисков.зато он хотя бы пытается хоть как-то проверить соответствие входящих параметров контракту класса, а не лепит непойми что из непойми чего по дефолту.
укажи мне, какой контракт мой код нарушает.
я привел реализацию ф-и в которой ты ожидал ошибку. где эта ошибка?
...
Рейтинг: 0 / 0
27.10.2010, 02:17
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921748
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNрезультат:
Rectangle(5,2);
Rectangle(2,5);ога, блестяще. Теперь приведи 2й результат к квадрату и во втором случае ты получишь квадрат 5*5 и скажи мне, можно вписать квадрат 5*5 в прямоугольник 2*10?
...
Рейтинг: 0 / 0
27.10.2010, 02:18
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921750
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych
кроме того, я получу хороший оверхед на том, что постоянно буду конструировать объекты вместо того, чтобы их изменять, но это вопрос уже из другой песни, оставим его пока

на счет оферхеда, во сколько раз размер прямоугольника превосходит тип double? я думаю раза в 2. и что это за липовый оверхед?
...
Рейтинг: 0 / 0
27.10.2010, 02:20
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921751
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNрезультат:
Rectangle(5,2);
Rectangle(2,5);ога, блестяще. Теперь приведи 2й результат к квадрату и во втором случае ты получишь квадрат 5*5 и скажи мне, можно вписать квадрат 5*5 в прямоугольник 2*10?

опять приведи к квадрату.
ты забыл о чем мы говорили?
мы говорили о старом коде который не знает о квадрате, и будет работать корректно.
...
Рейтинг: 0 / 0
27.10.2010, 02:21
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921752
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingizegorychна основании какой из аксиом квадрата, прямоугольника, или, не дай бог, ромба, следует, что квадрат конструируется из высоты прямоугольника?
а че не из площади или диагонали?
))
кста, если добавить аксиому к тем четырем, то это будет новый тип Square,
а не тот, с которого все началось.
не из площади ли диагонали потому, что это метод заказал ты, явно указал что нужно инорить ширину:
.
во первых, когда?
я про точное преобразование переживаю
...
Рейтинг: 0 / 0
27.10.2010, 02:21
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921754
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych,

найди мне в этой статье(или другой) - правило которому противоречит мой код.
http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%BF%D0%BE%D0%B4%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B8_%D0%9B%D0%B8%D1%81%D0%BA%D0%BE%D0%B2
...
Рейтинг: 0 / 0
27.10.2010, 02:23
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921755
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNмы берем метод setWidth, который возвращает прямоугольник основанный на объекте для которого его вызывают.назови его makeRectangle() и вопросы уйдут. Если я работаю с только с квадратами, на кой хрен мне сдался прямоугольник??? и да, я понимаю, что код не скомпилится, и я буду долго ломать голову, почему, потом, наконец, залезу с исходник твоего класса, если он у меня есть, или напишу тучу unit-тестов, чтобы выяснить, как работает твой класс. В конце концов я его выкину из проекта, как никуда не годный, и напишу свой квадрат, который всегда будет квадратом, и всем потом расскажу, какой плохой ты мне подсунул класс квадрата ;-))
но зато твой класс выполняет принцип подстановки Лисков, это единственная положительная в нём черта, правда практическая ценность которой, мне, к примеру, совершенно не очевидна.
...
Рейтинг: 0 / 0
27.10.2010, 02:24
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921756
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingiz
я про точное преобразование переживаю
1)я же процитировал тебя.
2) для неизменяемых объектов это не требуется.
тот пример Милнера(или как его там) - доказал не состоятельность подхода при работе с изменяемыми объектами.
...
Рейтинг: 0 / 0
27.10.2010, 02:25
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921757
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNмы берем метод setWidth, который возвращает прямоугольник основанный на объекте для которого его вызывают.назови его makeRectangle() и вопросы уйдут. Если я работаю с только с квадратами, на кой хрен мне сдался прямоугольник???
не надо прямоугольник? - юзай setWidth, но не надо забывать что квадрат является прямоугольником, и ты не можешь работать с квадратом не работая с прямоугольником, а на оборот можешь, в этом и разница между супертипом и подтипом.

если ты не хочешь работать с прямоугольником - не наследуй от него квадрат.
...
Рейтинг: 0 / 0
27.10.2010, 02:27
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921759
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNegorychZyK_BotaNрезультат:
Rectangle(5,2);
Rectangle(2,5);ога, блестяще. Теперь приведи 2й результат к квадрату и во втором случае ты получишь квадрат 5*5 и скажи мне, можно вписать квадрат 5*5 в прямоугольник 2*10?

опять приведи к квадрату.
ты забыл о чем мы говорили?
мы говорили о старом коде который не знает о квадрате, и будет работать корректно.и я об этом же. У меня есть квадрат и прямоугольник, мне нужно вписать в прямоугольник этот квадрат. И у меня есть функция, написанная для прямоугольников, логично ей воспользоваться, ты мне скажи? по мне, так логично. Берём, используем, всё компилируется, всё работает, и почти всегда корректно, за исключением некоторых данных, на которых результат получается неверным. Желаю приятных ночей в отладке такого бага )))
...
Рейтинг: 0 / 0
27.10.2010, 02:29
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921760
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych
но зато твой класс выполняет принцип подстановки Лисков, это единственная положительная в нём черта, правда практическая ценность которой, мне, к примеру, совершенно не очевидна.
тема началась с контрактов и подстановки Лисков.
я реализовал квадрат и прямоугольник, а вам не понравилось что он работает корректно.
вы все время хотите нарушить контракт.
...
Рейтинг: 0 / 0
27.10.2010, 02:29
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921762
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNесли ты не хочешь работать с прямоугольником - не наследуй от него квадрат.Ес! Я тебе об том и говорю, что нельзя наследовать квадрат от прямоугольника, потому что это разные фигуры, с некоторыми похожими свойствами, не более того.
...
Рейтинг: 0 / 0
27.10.2010, 02:31
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921763
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
автор
>> как неявное преобразования int к double объяснить. наверное int все же должен быть подтипом double.
1. никакого преобразования не происходит, если я выполняю операции в рамках одного типа.
2. как неявное преобразование double к int объяснить, наверное double всё же должен быть подтипом int ( самому не смешно? мне - смешно, например ))) )

смешного, кстати, ничего нет.

подкласс появляется когда в класс добавляют методы (функции)
к группе целых по сложению добавили операцию умножения и деления и получили поле рациональных. В подклассе увеличился домен класса.
и рациональные таки могут трактоваться как подкласс целых.
А целые могут трактоваться как подкласс натуральных.
К полугруппе натуральных по умножению добавили операция взятия обратного и получили группу
целых.

Более, того любой нормальное наследование которые вы делаете проходит по схеме увеличения домена класса.
Доменом класса было декартово произведение длиной n, наследовали класс с добавлением одного поля. Получили домен класса из декартового произведения длинной n+1
...
Рейтинг: 0 / 0
27.10.2010, 02:33
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921764
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaNegorych
но зато твой класс выполняет принцип подстановки Лисков, это единственная положительная в нём черта, правда практическая ценность которой, мне, к примеру, совершенно не очевидна.
тема началась с контрактов и подстановки Лисков.
я реализовал квадрат и прямоугольник, а вам не понравилось что он работает корректно.
вы все время хотите нарушить контракт.предыдущий абзац остался не прочитанным, штоле?
...
Рейтинг: 0 / 0
27.10.2010, 02:33
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921765
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaNegorychZyK_BotaNрезультат:
Rectangle(5,2);
Rectangle(2,5);ога, блестяще. Теперь приведи 2й результат к квадрату и во втором случае ты получишь квадрат 5*5 и скажи мне, можно вписать квадрат 5*5 в прямоугольник 2*10?

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

нет не логично.
у меня есть ф-я sin, я подставляю целое, а получаю в результате дробь.
здесь то же самое. пользуйся ф-й на здоровье, но она возвращает не квадрат а прямоугольник.
...
Рейтинг: 0 / 0
27.10.2010, 02:34
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921767
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychназови его makeRectangle() и вопросы уйдут. Если я работаю с только с квадратами, на кой хрен мне сдался прямоугольник??? и да, я понимаю, что код не скомпилится, и я буду долго ломать голову, почему, потом, наконец, залезу с исходник твоего класса, если он у меня есть, или напишу тучу unit-тестов, чтобы выяснить, как работает твой класс.

что-бы выяснить как работает мой класс нужно миниммум усилий. нет ни виртуальных ф-й, ни исключительных ситуаций.
На месте прямоугольника, квадрат работает точь-в-точь как прямоугольник. - это главный принцип. принцип подстановки Лисков.
а то что ты предложил ему противоречит.
...
Рейтинг: 0 / 0
27.10.2010, 02:37
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921768
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
авторНа месте прямоугольника, квадрат работает точь-в-точь как прямоугольник
это главный принцип. принцип подстановки Лисков
ой. не верю.
не правда. это не тот принцип.
...
Рейтинг: 0 / 0
27.10.2010, 02:40
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921769
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychназови его makeRectangle()
зачем называть makeRectangle, если программист посмотрит на сигнатуру и увидит, что возвращается прямоугольник.
...
Рейтинг: 0 / 0
27.10.2010, 02:40
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921770
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
к матам только не переходите.
а я пойду поработаю
...
Рейтинг: 0 / 0
27.10.2010, 02:41
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921771
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizавторНа месте прямоугольника, квадрат работает точь-в-точь как прямоугольник
это главный принцип. принцип подстановки Лисков
ой. не верю.
не правда. это не тот принцип.

тогда просвяти меня. я серьезно.
видимо я неправильно трактую этот принцип. но что характерно, в моей реализации он точно не нарушается.
...
Рейтинг: 0 / 0
27.10.2010, 02:41
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921772
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaN,
>>у меня есть ф-я sin, я подставляю целое, а получаю в результате дробь.
функция sin принимает значение типа double и возращает значение типа double, все знают, что такое синус, и все знают, как квадрат вписать в прямоугольник.

>>здесь то же самое. пользуйся ф-й на здоровье, но она возвращает не квадрат а прямоугольник.
ну чтож, дебаггер в зубы, и приятных ночей в отладке, чтобы понять, почему иногда квадрат в итоге получается нормальный, а иногда - нет.
вот если бы функция sin для некоторых целых чисел возвращала-бы мне значение, большее единицы, то я тогда бы с тобой согласился, что ситуация - нормальная, а мне просто не повезло, и надо написать ещё один синус, для целых
...
Рейтинг: 0 / 0
27.10.2010, 02:42
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921774
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaN,
>>у меня есть ф-я sin, я подставляю целое, а получаю в результате дробь.
функция sin принимает значение типа double и возращает значение типа double, все знают, что такое синус, и все знают, как квадрат вписать в прямоугольник.


великолепно
ф-я setWidth принимает(неявно) объект типа прямоугольник и возвращает прямоугольник.
...
Рейтинг: 0 / 0
27.10.2010, 02:43
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921775
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
как еще?
во первых он написан не идеально.
Тем более, перевод.

во вторых, лично моя версия лучшей трактовки так звучит

автор
Пока, в свете предыдущих договоренностей,
принцип подстановки Лисков может трактоваться следующим образом:

.n
Пусть T и S некоторые классы. Если любая программа, использующая
обращения к переменной t: T, продолжает удовлетворять своей
спецификации при присвоении t значения любой переменной s: S,
то тип класса S является подтипом спецификации T.
.f
...
Рейтинг: 0 / 0
27.10.2010, 02:44
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921776
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizкак еще?
во первых он написан не идеально.
Тем более, перевод.

во вторых, лично моя версия лучшей трактовки так звучит

автор
Пока, в свете предыдущих договоренностей,
принцип подстановки Лисков может трактоваться следующим образом:

.n
Пусть T и S некоторые классы. Если любая программа, использующая
обращения к переменной t: T, продолжает удовлетворять своей
спецификации при присвоении t значения любой переменной s: S,
то тип класса S является подтипом спецификации T.
.f


тогда мой код удовлетворяет этому принципу.
при передаче параметра нет разници что мы напишем. Rectangle(5, 5) или Square(5), во втором случае 1-й конструктор будет вызван неявно.
...
Рейтинг: 0 / 0
27.10.2010, 02:46
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921777
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaN

тогда просвяти меня. я серьезно.
видимо я неправильно трактую этот принцип. но что характерно, в моей реализации он точно не нарушается.
в третьих, таки сделай отдельный код для квадратов и прямоугольников. поменьше что бы было.
я на выходных сделаю такой же наоборот, наследую прямоугольник из квадрата, в твоей манере
если пойму ее.
...
Рейтинг: 0 / 0
27.10.2010, 02:46
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921778
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingizкак еще?
во первых он написан не идеально.
Тем более, перевод.

во вторых, лично моя версия лучшей трактовки так звучит

автор
Пока, в свете предыдущих договоренностей,
принцип подстановки Лисков может трактоваться следующим образом:

.n
Пусть T и S некоторые классы. Если любая программа, использующая
обращения к переменной t: T, продолжает удовлетворять своей
спецификации при присвоении t значения любой переменной s: S,
то тип класса S является подтипом спецификации T.
.f


тогда мой код удовлетворяет этому принципу.
при передаче параметра нет разници что мы напишем. Rectangle(5, 5) или Square(5), во втором случае 1-й конструктор будет вызван неявно.
может он у тебя и подтип
...
Рейтинг: 0 / 0
27.10.2010, 02:47
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921779
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ZyK_BotaN На месте прямоугольника, квадрат работает точь-в-точь как прямоугольник. - это главный принцип. принцип подстановки Лисков.
а то что ты предложил ему противоречит.если для соблюдения теоретических принципов мне приходится вводить дополнительные ограничения на использование моего кода, то это говорит о том, что есть ошибка в предположении, что этот принцип здесь применим, только и всего. Если есть контракт, что прямоугольник является квадратом тогда и только тогда, когда его высота равна ширине, то я не могу конструировать квадрат из прямоугольника произвольным образом, а _должен_ этот контракт проверить, понимаешь меня? Отсюда следует только один вывод - нельзя квадрат наследовать от прямоугольника, ибо это нарушает контракт класса и принцип подстановки Лисков.
...
Рейтинг: 0 / 0
27.10.2010, 02:52
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921781
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
egorych,

всё, я сдался, наследуй чего хочешь от чего хочешь, главное, выполняй формально принцип ;-))

ЗЫ спасибо за отличную беседу, кстати. Мне было интересно ))
...
Рейтинг: 0 / 0
27.10.2010, 02:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921782
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingizZyK_BotaN

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

думаю не сможешь.

 
Код: 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.
class Rectangle {
	double w,h;
public:
	Rectangle(double iw, double ih) {
		w = iw;
		h = ih;
	}
	Rectangle setWidth(double newW) {
		return Rectangle(newW, h);
	}
	Rectangle setHeight(double newH) {
		return Rectangle(w, newH);
	}
	double getWidth() {
		return w;
	}
	double getHeight() {
		return h;
	}
	double getSpace() {
		return w*h;
	}
};
class Square: public Rectangle {
public:	
	Square(double side) : Rectangle(side, side){}
	Square setSide(double newSide) {
		return Square( newSide );
	}

};
    void showRectangle(Rectangle r) {
		std::cout << "Rectangle(" << r.getWidth() << "," << r.getHeight() << ")" << std::endl;
	}
	void showSquare(Square s) {
		std::cout << "Square(" << s.getWidth() << ")" << std::endl;
	}


 

	double sumOfSpace(std::vector<Rectangle> rs) {
		double sum =  0 ;
		for (std::vector<Rectangle>::iterator i = rs.begin(); i != rs.end(); ++i) {
			sum += (*i).getSpace();
		}
		return sum;
	}


я специально оставил ф-ю сумы полщадей, так как на ней, ИМХО, код и сломается
...
Рейтинг: 0 / 0
27.10.2010, 02:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921783
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychZyK_BotaN На месте прямоугольника, квадрат работает точь-в-точь как прямоугольник. - это главный принцип. принцип подстановки Лисков.
а то что ты предложил ему противоречит.если для соблюдения теоретических принципов мне приходится вводить дополнительные ограничения на использование моего кода, то это говорит о том, что есть ошибка в предположении, что этот принцип здесь применим, только и всего. Если есть контракт, что прямоугольник является квадратом тогда и только тогда, когда его высота равна ширине, то я не могу конструировать квадрат из прямоугольника произвольным образом, а _должен_ этот контракт проверить, понимаешь меня? Отсюда следует только один вывод - нельзя квадрат наследовать от прямоугольника, ибо это нарушает контракт класса и принцип подстановки Лисков.

если не соблюдать тер. принципы, то у нас вылезут ошибке.
мое мнение, принцип Лисков важен для понимания опасности наследования классов.
конечно, избегать изменяемое состояния и полный отказ от виртуальных методов - зло, но минимизировав их использования мы получаем более очевидный не подверженный ошибкам код.
...
Рейтинг: 0 / 0
27.10.2010, 03:00
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921786
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorychegorych,

всё, я сдался, наследуй чего хочешь от чего хочешь, главное, выполняй формально принцип ;-))

ЗЫ спасибо за отличную беседу, кстати. Мне было интересно ))

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

(pascal+haskel) vs (Cи)
ты же сишник?, я то предположил из-за того что для тебя нормально 1/2 = 0.
даже в 3-м питоне это исправили(или наоборот, я уже не помню).
...
Рейтинг: 0 / 0
27.10.2010, 03:07
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921859
Фотография k0rvin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
k0rvin
Участник
ZyK_BotaNвот пример иерархии типов хаскелла, в подтверждение что не только я считаю Целые подтипом Вещественных:


это не иерархия типов, а иерархия классов типов и никаким подтипом Вещественных Целые в Хаскелле не являются.
...
Рейтинг: 0 / 0
27.10.2010, 08:14
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921866
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN,

Есть еще принцип Open-Close, который ты нарушил. Потому твой код ужасен.

Мне лень листать, но по моему твой код работает верно,потому что в нем нет квадратов. Все неявно (конструкторами) преобразовывается в прямоугольники.
...
Рейтинг: 0 / 0
27.10.2010, 08:21
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921884
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
авторВещественных Целые в Хаскелле не являются.
более, того как выяснено в
// http://www.sql.ru/forum/actualthread.aspx?tid=795626&pg=1
и не могут являться.
так же как натуральные не подтип целых.
...
Рейтинг: 0 / 0
27.10.2010, 08:41
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921958
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingizа нужно сделать, чтобы передать ребенка в ранее написанные программы
для родителя
ранее написанные программы для родителя принимают тип ребенка без преобразования (или я что-то не понимаю ?).
...
Рейтинг: 0 / 0
27.10.2010, 09:35
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921965
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingizто можно вызывать методы родителя сколько угодно.
методы родителя к ребенку можно вызывать сколько угодно без всяких ЕСЛИ. Другое дело, что может быть отказ в их исполнении по аксиомам ребенка.
...
Рейтинг: 0 / 0
27.10.2010, 09:39
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36921979
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingizя с твоего позволения буду называть множество_допустимых_значений
доменом типа, ибо тип - это спецификация класса, то есть, набор аксиом.
Так набор аксиом и определяет домен. И зачем вводить новые сущности :)
tchingizпиши функции, не включая в класс. Это будут функции не включенные в класс.
А зачем тогда класс вообще. Понятие модуль гораздо конструктивнее.
tchingiz
Среди множества всех написанных функций, желательно выделить
подмножество таких, которые нельзя написать через другие, и их то и вносить
в класс.
Так это и есть базовые типы данных ЯП (можество значений -аксиом и набор операций-функций). Все остальное можно написать самому.
...
Рейтинг: 0 / 0
27.10.2010, 09:48
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922073
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingizподкласс появляется когда в класс добавляют методы (функции)
к группе целых по сложению добавили операцию умножения и деления и получили поле рациональных.
Нет, это ошибка проектирования ЯП. Добавление операции не расширяет тип.
Код: plaintext
1.
2.
3.
4.
5.
int (+,-,*,div)
int c
с= 1  div  2   - c= 0 
c= 1 / 2   -  ошибка - справа float, слева int
c=int( 1 / 2 ) - с= 0
...
Рейтинг: 0 / 0
27.10.2010, 10:28
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922089
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingiz присвоении t значения любой переменной s: S,
Любой нормальный компилятор обругает такое присваивание :) или хотя-бы предупредит
...
Рейтинг: 0 / 0
27.10.2010, 10:33
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922293
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,
Мне лень листать, но по моему твой код работает верно,потому что в нем нет квадратов. Все неявно (конструкторами) преобразовывается в прямоугольники.

но в методы которые работаю только с квадратом, мы можем передать только квадрат. в этом и смысл.

а как в с++ можно реализовать подтип, который не вызывает конструктор суперкласса? и что в этом плохого?

я так понял с ваших слов, что проблема моего кода в том, что он работает.
...
Рейтинг: 0 / 0
27.10.2010, 11:53
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922311
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
k0rvin[quot ZyK_BotaN]вот пример иерархии типов хаскелла, в подтверждение что не только я считаю Целые подтипом Вещественных:
это не иерархия типов, а иерархия классов типов и никаким подтипом Вещественных Целые в Хаскелле не являются.

класс Integral является подтипом класса Real. или я что-то не понимаю?
просто в хаскеле нужно явно приводить объект дочернего класса к родительскому.

я к тому, что имена операций деления и возведения в степень отличаются от целочисленных аналогов.
...
Рейтинг: 0 / 0
27.10.2010, 11:58
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922324
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,

Есть еще принцип Open-Close, который ты нарушил. Потому твой код ужасен.


Принцип Открытости-Закрытости (Open Close Principle или OCP)

Программные сущности такие как классы, модули и функции должны быть открыты для расширения, но закрыты для изменений.

у меня они как раз открыты для расширения и закрыты для изменения. все ок. где нарушение?
...
Рейтинг: 0 / 0
27.10.2010, 12:02
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922343
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
_модtchingiz присвоении t значения любой переменной s: S,
Любой нормальный компилятор обругает такое присваивание :) или хотя-бы предупредит

да нет, там вроде все нормально написано, и компиляторы вроде не ругаются.
...
Рейтинг: 0 / 0
27.10.2010, 12:07
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922433
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
ZyK_BotaNда нет, там вроде все нормально написано, и компиляторы вроде не ругаются.
Переменные ведь разных типов - компилятор предупредит (должен), что будет преобразование.
Плохое определение, вообщем.
...
Рейтинг: 0 / 0
27.10.2010, 12:34
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922440
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
_модZyK_BotaNда нет, там вроде все нормально написано, и компиляторы вроде не ругаются.
Переменные ведь разных типов - компилятор предупредит (должен), что будет преобразование.
Плохое определение, вообщем.
как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
...
Рейтинг: 0 / 0
27.10.2010, 12:37
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922459
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
ZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
...
Рейтинг: 0 / 0
27.10.2010, 12:42
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922468
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
_модZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
можешь назвать о компиляторах каких языков ты говоришь.
...
Рейтинг: 0 / 0
27.10.2010, 12:44
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922558
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
Кстати, у Лисков правильно написано - не присвоение t=s, а подстановка вместо t s.
Т.е. методы t непосредственно применяются к s и при этом их поведение не меняется.
К случаю квадратов и прям-ов это полностью подходит, т.к. методы прям-ов на квадратах либо нормально работают, либо не работают совсем. Но поведение их не меняется.
зы Нужно делать, как в динамических языках - левая часть принимает тип правой. То же и при передаче парметров, т.е. в методы прям-ов передаются квадраты без преобразования типов.
...
Рейтинг: 0 / 0
27.10.2010, 13:08
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922625
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
ZyK_BotaNможешь назвать о компиляторах каких языков ты говоришь.
Последний такой был pl/1. М.б. какой-нить паскаль. Но мне больше нравится подход в динамических языках: переменная принимает тип выражения из правой части.
...
Рейтинг: 0 / 0
27.10.2010, 13:23
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36922656
Фотография k0rvin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
k0rvin
Участник
ZyK_BotaN класс Integral является подтипом класса Real.
как это понимать?
"тип подтипом типа" понимаю,
"класс субклассом класса" понимаю,
"класс подтипом класса" не понимаю =/

ZyK_BotaNили я что-то не понимаю?
скорее что-то путаешь.

ZyK_BotaNпросто в хаскеле нужно явно приводить объект дочернего класса к родительскому.
не совсем, многие классы предоставляют функции преобразования, выполняющиеся автоматически, типа fromInteger, fromEnum, toEnum, etc

ZyK_BotaNя к тому, что имена операций деления и возведения в степень отличаются от целочисленных аналогов.
это [почти] везде где так
...
Рейтинг: 0 / 0
27.10.2010, 13:31
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36923567
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
k0rvin
это [почти] везде где так
ну а я это указал для тех, для кого 1/2 = 0 - является интуитивно понятным.

k0rvin
"класс подтипом класса" не понимаю

виноват исправлюсь
...
Рейтинг: 0 / 0
27.10.2010, 17:14
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36923717
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
k0rvin
не совсем, многие классы предоставляют функции преобразования, выполняющиеся автоматически, типа fromInteger, fromEnum, toEnum, etc


но это ведь происходит без потери точности?
...
Рейтинг: 0 / 0
27.10.2010, 17:41
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924047
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
_модZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
без преобразования.
если рассматривать нормальное наследование, а не эти идиотские примеры,
как у нас, то будет понятно, что при наследовании в подкласс добавляются
поля. Это увеличение на одну размерность кортежа.
При преобразовании ребенка в родителя - это поле надо отбросить.
Тогда об обратном преобразовании можно не мечтать, информация утеряна.

пысы


ДмидекМемберы Siemargl и egorych добавлены в ЗПТ.
Чингиз - традиционный вопрос - ты им сообщишь при оказии или
мне написать письма ? :-)
...
Рейтинг: 0 / 0
27.10.2010, 20:03
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924068
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
tchingiz, понял про ЗПТ, типа спс за доверие.

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

ZyK_BotaN, пример слишком тривиален (и дажи при том ты ромб выбросил, как неудобный=) и неопределены аксиомы, чтобы на нем тренировать.
...
Рейтинг: 0 / 0
27.10.2010, 20:18
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924078
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
не неудобный ромб, а мы его попросили, ато долго думать при длинном примере.
Его мысль все равно видна будет.
...
Рейтинг: 0 / 0
27.10.2010, 20:25
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924085
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
Siemargltchingiz, понял про ЗПТ, типа спс за доверие.

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

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

двай, изобретай. но что за проблема с аксиомами.
и самое главное ты не ответил на вопрос про открытость/закрытость
...
Рейтинг: 0 / 0
27.10.2010, 20:27
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924122
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaNи самое главное ты не ответил на вопрос про открытость/закрытость
Речь об этих классах.

Пример такой. Написал ты стороннюю коллекцию.
Пусть без ромба. Пусть vector<Rectangle*> (без указателя типы приведутся и потеряются).
Нужно все элементы коллекции скажем, уменьшить вдвое.
Но у тебя Rectangle::setWidth() и Square::setSide()

Чтобы написать коллекцию, тебе придется "открыть" классы и внести в них изменения, добавив общий метод.

Второе нарушение тут.
Код: plaintext
\tSquare(Rectangle r) : Rectangle(r.getHeight(),r.getHeight()),\n\t\tRhomb( 90 , r.getHeight()) {\n\n\t}\n\tSquare(Rhomb r) : Rectangle(r.getSide(),r.getSide()),\n\t\tRhomb( 90 , r.getSide())
Появится еще одна фигура - тебе придется переписать и ее наследников по иерархии, чтобы учесть ее ньюансы.
...
Рейтинг: 0 / 0
27.10.2010, 20:55
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924234
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaNи самое главное ты не ответил на вопрос про открытость/закрытость
Речь об этих классах.

Пример такой. Написал ты стороннюю коллекцию.
Пусть без ромба. Пусть vector<Rectangle*> (без указателя типы приведутся и потеряются).
Нужно все элементы коллекции скажем, уменьшить вдвое.
Но у тебя Rectangle::setWidth() и Square::setSide()

Чтобы написать коллекцию, тебе придется "открыть" классы и внести в них изменения, добавив общий метод.

действительно, передача по ссылку все портит. придется запрещать и ссылку.
недаром в с++, так можно
Код: plaintext
const double& c =  1 \n
а так нельзя
Код: plaintext
double& c =  1
я был не прав, что не заметил такой дыры. Но с++ я выбрал, что-бы показать множ. наследование. а так здесь идут теоретические рассуждения. я заранее предупредил, что объекты должны быть иммутабельны.
у меня вся фишка в иммутабельности, а сдесь она нарушается.
но - это с++ с его выкрутасами, там даже константу можно изменить.
а поломаешь ли ты аналогичный код на java?
если есть здесь опытные с++-ки, подскажите можно ли сделать класс неизменяемых объектов в С++, не потеряв возможность наследоваться.

Siemargl
Второе нарушение тут.
Код: plaintext
\tSquare(Rectangle r) : Rectangle(r.getHeight(),r.getHeight()),\n\t\tRhomb( 90 , r.getHeight()) {\n\n\t}\n\tSquare(Rhomb r) : Rectangle(r.getSide(),r.getSide()),\n\t\tRhomb( 90 , r.getSide())
Появится еще одна фигура - тебе придется переписать и ее наследников по иерархии, чтобы учесть ее ньюансы.

зачем? разве в принципе о/з сказано про то что можно изменять супер классы?
я лишь увидел что можно расширять наследников и запрещено ломать родительские классы.
...
Рейтинг: 0 / 0
27.10.2010, 22:13
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924283
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN,

1. Мне кажется, что ты неверно понимаешь иммутабельность.
2. Иммутабельность часто неудобна в реальной работе, чтобы на ней ставить икону. Кроме того, в С++ иммутабельности нет и в Java вроде бы тоже. (Она есть в D - и если поискать - можно найти статью Брайта, где поясняется отличие C++ const от D immutable)
3. Второе нарушение не относится к принципу о/з.
...
Рейтинг: 0 / 0
27.10.2010, 22:29
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924303
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Я придумал пример. Геймдев, RTS.
Владелец - поле боя.
Класс 1. Статический тайл. Контракт - всегда валиден.
Класс 2. Динамический тайл. Может быть разрушен. Контракт - не разрушен.
Класс 3. NPC. Может быть заморожен. Контракт - не заморожен.
Класс 4. User's soldier. Может управляться человеком. Контракт - жив, бегает.
...
Рейтинг: 0 / 0
27.10.2010, 22:41
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924316
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,

1. Мне кажется, что ты неверно понимаешь иммутабельность.
2. Иммутабельность часто неудобна в реальной работе, чтобы на ней ставить икону. Кроме того, в С++ иммутабельности нет и в Java вроде бы тоже. (Она есть в D - и если поискать - можно найти статью Брайта, где поясняется отличие C++ const от D immutable)
3. Второе нарушение не относится к принципу о/з.

в джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.
а в с++ можно все .
...
Рейтинг: 0 / 0
27.10.2010, 22:51
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924324
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN,


2. Иммутабельность часто неудобна в реальной работе.

согласен. но в данном случае она обязательна, и иначе иерархия ломается.

Siemargl
3. Второе нарушение не относится к принципу о/з.
можно на пальцах?
...
Рейтинг: 0 / 0
27.10.2010, 22:54
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924338
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaN, давай про солдатиков придумывай.

Кстати, вспомнил историю из геймдева. Когда игра падала - потому что для свиньи вызывался метод "стрелять", а пистолета - то нету )
...
Рейтинг: 0 / 0
27.10.2010, 23:07
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924341
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
ZyK_BotaN
Siemargl
3. Второе нарушение не относится к принципу о/з.
можно на пальцах?
а точнее, если не относится к принципу о/з то в чем проблема?
имхо, это не нормально добавлять в иерархию наследования класс, и хотеть, что-бы наследники об этом не знали.
...
Рейтинг: 0 / 0
27.10.2010, 23:08
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924343
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaN, давай про солдатиков придумывай.

Кстати, вспомнил историю из геймдева. Когда игра падала - потому что для свиньи вызывался метод "стрелять", а пистолета - то нету )
блицкриг?
там еще есть байка:
отнаследовали ракету от летающего аппарата.
и в плохую погоду ракета возвращалась на базу
...
Рейтинг: 0 / 0
27.10.2010, 23:09
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924478
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
ДмидекМемберы Siemargl и egorych добавлены в ЗПТ.сэнкс, тронут ;-))
...
Рейтинг: 0 / 0
28.10.2010, 01:38
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924484
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
тут люди прямо жить не могут без виртуальных функций
и позднего связывания - динамическая диспетчеризация
...
Рейтинг: 0 / 0
28.10.2010, 01:57
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924486
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
tchingiz_модZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
без преобразования.
если рассматривать нормальное наследование, а не эти идиотские примеры,
как у нас, то будет понятно, что при наследовании в подкласс добавляются
поля. Это увеличение на одну размерность кортежа.
При преобразовании ребенка в родителя - это поле надо отбросить.
Тогда об обратном преобразовании можно не мечтать, информация утеряна.

дивное единодушие во мнении с классиками
...
Рейтинг: 0 / 0
28.10.2010, 02:04
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924487
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
subsumption -- это правило категоризации, ребенок отнесен к категории (типу) родителя.
...
Рейтинг: 0 / 0
28.10.2010, 02:07
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924491
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
tchingizZyK_BotaNtchingizZyK_BotaN
тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.
с потерей точности - да.
поэтому в жизни вещественные - целые ( целые - натуральне) есть,
а по принципу Лисков их нельзя преобразовать. Они - разные типы.

авторПусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
где здесь про перобразование типов от родительского к дочернему?
я тебе рассказывал, что оно неявно всплывает.
Оно всплывает у Мартина когда он рассматривает первый шаг -
после преобразования ребенка в родителя вызывает родительский метод.
Метод нарушает инвариант ребенка, что делает невозможным обратное преобразование в ребенка.
глава type information, lost and found в теории объектов Карделли целиком посвящена
сохранению всех атрибутов ребенка.
Послкольку они сохраняются, сохраняется возможность обратного преобразования.
...
Рейтинг: 0 / 0
28.10.2010, 02:24
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924652
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
ZyK_BotaNв джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.В Java все объекты - ссылки.

tchingizглава type information, lost and found в теории объектов Карделли целиком посвящена
сохранению всех атрибутов ребенка.
Послкольку они сохраняются, сохраняется возможность обратного преобразования.
В языках, где объекты только в динамической памяти - Java, .NET, D, Delphi проблем потери атрибутов нет. Преобразовывай куда хочешь.
...
Рейтинг: 0 / 0
28.10.2010, 09:09
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924745
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
tchingizесли рассматривать нормальное наследование, а не эти идиотские примеры,
как у нас, то будет понятно, что при наследовании в подкласс добавляются
поля. Это увеличение на одну размерность кортежа.
При преобразовании ребенка в родителя - это поле надо отбросить.
Тогда об обратном преобразовании можно не мечтать, информация утеряна.

Фокус в том, что никаких (неявных) преобразований типов не д.б. вообще. А вся проблема в ЯП с жесткой типизацией.
Код: plaintext
1.
2.
3.
4.
float a
int b
b= 1    - тип b - int
a=b   - тип a - float что неверно, а д.б. int
Т.е. переменная должна изменять свой тип в соотв. с присвоенным ей выражением. В динамически типизированных ЯП это всегда так. Вот тогда и будет нормальное наследование и истинный полиморфизм. Ф-ия ident(x) -> x возвращает x с сохранением его типа. И тогда методы родителя непосредственно применяются к ребенку, подстраиваясь под его тип. Вот тогда и принцип Лисков заработает.
...
Рейтинг: 0 / 0
28.10.2010, 09:49
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36924759
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
ZyK_BotaNу меня вся фишка в иммутабельности
Чисто функциональное программирование действительно снимает все проблемы. Вот только оно никак не согласуется с парадигмой БД, в которой как раз и хранятся изменяющиеся объекты, причем очень разных типов.
...
Рейтинг: 0 / 0
28.10.2010, 09:55
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36925269
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
SiemarglZyK_BotaNв джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.В Java все объекты - ссылки.


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

а в с++, зная адрес объекта, можно его подменить.
...
Рейтинг: 0 / 0
28.10.2010, 12:56
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36925276
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
Siemargl
Послкольку они сохраняются, сохраняется возможность обратного преобразования.
В языках, где объекты только в динамической памяти - Java, .NET, D, Delphi проблем потери атрибутов нет. Преобразовывай куда хочешь.[/quot]

на счет Delphi уверен?
а то я когда-то писал на нем, и вроде на стеке объекты создавал. хотя точно не помню.
...
Рейтинг: 0 / 0
28.10.2010, 12:57
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36925280
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
_модZyK_BotaNу меня вся фишка в иммутабельности
Чисто функциональное программирование действительно снимает все проблемы. Вот только оно никак не согласуется с парадигмой БД, в которой как раз и хранятся изменяющиеся объекты, причем очень разных типов.
согласен.
...
Рейтинг: 0 / 0
28.10.2010, 12:58
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36926015
--------------------------------
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
--------------------------------
Гость
_модZyK_BotaNу меня вся фишка в иммутабельности
Чисто функциональное программирование действительно снимает все проблемы. Вот только оно никак не согласуется с парадигмой БД, в которой как раз и хранятся изменяющиеся объекты, причем очень разных типов.
С парадигмой тоже не все очевидно.
Создания битемпоральных баз данных - это практически использование иммутабельных объектов.
...
Рейтинг: 0 / 0
28.10.2010, 16:06
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36926112
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
--------------------------------С парадигмой тоже не все очевидно.
Создания битемпоральных баз данных - это практически использование иммутабельных объектов.
Сложно представить работу такой БД в многопользовательской среде
...
Рейтинг: 0 / 0
28.10.2010, 16:31
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36926155
--------------------------------
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
--------------------------------
Гость
_мод
Сложно представить работу такой БД в многопользовательской среде
А что не так в многопользовательской?
Чем хуже, чем в однопользовательской?
Или ты имел в виду - когда идет много обновлений?
...
Рейтинг: 0 / 0
28.10.2010, 16:42
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36926742
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
_мод--------------------------------С парадигмой тоже не все очевидно.
Создания битемпоральных баз данных - это практически использование иммутабельных объектов.
Сложно представить работу такой БД в многопользовательской среде

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

K:
http://kx.com/
...
Рейтинг: 0 / 0
28.10.2010, 22:19
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36928950
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
Siemargltchingiz, понял про ЗПТ, типа спс за доверие.

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

ZyK_BotaN, пример слишком тривиален (и дажи при том ты ромб выбросил, как неудобный=) и неопределены аксиомы, чтобы на нем тренировать.
для классического примера Мартина я их записал.
...
Рейтинг: 0 / 0
30.10.2010, 03:36
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36928952
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
_модZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
во первых, S подкласс, T надкласс.
во вторых, не ругаются.
Из подкласса в надкласс присваивать можно. Это не ошибка.
Это такое поведение компиляторов было заложено в них и постулировалось.
А потом начались сомнения и Лисков придумала принцип.
...
Рейтинг: 0 / 0
30.10.2010, 03:39
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36928953
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
SiemarglZyK_BotaNв джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.В Java все объекты - ссылки.

tchingizглава type information, lost and found в теории объектов Карделли целиком посвящена
сохранению всех атрибутов ребенка.
Послкольку они сохраняются, сохраняется возможность обратного преобразования.
В языках, где объекты только в динамической памяти - Java, .NET, D, Delphi проблем потери атрибутов нет. Преобразовывай куда хочешь.
не имеет значения где живут объекты.
Классики (Карделли и Абади в теории объектов) разрешили думать в наивной модели памяти, где переменная, объявленная классом,
- это ссылка на запись. При присвоении и передаче параметров не происходит никакого преобразования значений ( то есть записи).
происходит преобразование вида ссылки
...
Рейтинг: 0 / 0
30.10.2010, 03:58
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36928954
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
parameter passing and assignment copy references, not the associated attribute records.
...
Рейтинг: 0 / 0
30.10.2010, 04:02
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36928959
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
tchingiz_модZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
во первых, S подкласс, T надкласс.
во вторых, не ругаются.
Из подкласса в надкласс присваивать можно. Это не ошибка.
так уже для порядку


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

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

Код: plaintext
p: POLYGON; r: RECTANGLE; t: TRIANGLE


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


Эти команды присваивают в качестве значения сущности, обозначающей многоугольник, сущность, обозначающую прямоугольник в первом случае, и сущность, обозначающую треугольник - во втором.
...
Рейтинг: 0 / 0
30.10.2010, 04:36
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36928967
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNegorychназови его makeRectangle() и вопросы уйдут. Если я работаю с только с квадратами, на кой хрен мне сдался прямоугольник??? и да, я понимаю, что код не скомпилится, и я буду долго ломать голову, почему, потом, наконец, залезу с исходник твоего класса, если он у меня есть, или напишу тучу unit-тестов, чтобы выяснить, как работает твой класс.

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

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



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

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

здесь В - ребенок, А - родитель, статическое связывание - ранне связывание == вызов метода родителя
...
Рейтинг: 0 / 0
30.10.2010, 05:25
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929084
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
tchingiz, вот да, именно это я и пытался донести нашему общему другу ZiK_BotaN.

PS используя его технику легко отнаследовать квадрат от круга, например.. Но это же абсурд
PSS tchigiz, красивенько получилось :-))
...
Рейтинг: 0 / 0
30.10.2010, 12:21
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929270
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
egorych
PS используя его технику легко отнаследовать квадрат от круга, например.. Но это же абсурд


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

Моя техника базировалась на том, что квадрат всегда является прямоугольником, наоборот уже не верно.
а кругом квадрат не может являться в принципе.
...
Рейтинг: 0 / 0
30.10.2010, 17:37
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929274
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingiz
1
на месте прямоугольника, квадрат не должен работать в точь-в-точь как прямоугольник.

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

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

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


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

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

моим решением, является иерархия представленная выше, но у нее есть огромный недостаток - неизменяемость данных. как решить ту же проблему для изменяемых объектов я не знаю.
...
Рейтинг: 0 / 0
30.10.2010, 17:50
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929295
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
ZyK_BotaNа кругом квадрат не может являться в принципе.
а ты попобуй сжать квадрат в точку
...
Рейтинг: 0 / 0
30.10.2010, 18:22
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929300
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
ViPRosZyK_BotaNа кругом квадрат не может являться в принципе.
а ты попобуй сжать квадрат в точку

и как это мне поможет?
если на то пошло, то я могу точку от квадрата отнаследовать , но не квадрат от круга
...
Рейтинг: 0 / 0
30.10.2010, 18:36
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929323
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
ZyK_BotaN,

к сжалению, забыл топологию вскяие там морфизмы и т.д
...
Рейтинг: 0 / 0
30.10.2010, 19:19
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929537
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
это не топология, а теория категорий.






пысы
ну, у Сибилева и ЛаТех, шоб он был здоров.
Поехать мозгом можно, пока нарисуешь
...
Рейтинг: 0 / 0
31.10.2010, 00:39
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929540
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
...
Рейтинг: 0 / 0
31.10.2010, 00:52
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929553
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
ZyK_BotaNtchingiz
1
на месте прямоугольника, квадрат не должен работать в точь-в-точь как прямоугольник.

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

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

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

--
1 2 3 4 5 - каждый N - й класс, является подклассом предыдушего N-1.
Причем на каждом шаге домен класса или расширяется или остается тем же самым.

тип 3 не является подтипом 2.
тип 5 не является подтипом 4
...
Рейтинг: 0 / 0
31.10.2010, 01:29
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929557
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
egorychtchingiz, вот да, именно это я и пытался донести нашему общему другу ZiK_BotaN.

PS используя его технику легко отнаследовать квадрат от круга, например.. Но это же абсурд
PSS tchigiz, красивенько получилось :-))
на этой радостной ноте пишем обобщение принципа подстановки Лисков
до критерия подстановки



автор

Пусть T и S некоторые классы. Любая программа P, использующая
обращения к переменной t: T, продолжает удовлетворять своей
спецификации при присвоении t значения любой переменной s: S,
с возможностью обратного присваивания нового значения из t в s после выполнения P,
тогда и только тогда, когда спецификация класса (тип) S является подтипом спецификации класса (типа)T.
...
Рейтинг: 0 / 0
31.10.2010, 01:37
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929559
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZyK_BotaN
Участник
tchingiz,

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

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

моим решением, является иерархия представленная выше, но у нее есть огромный недостаток - неизменяемость данных. как решить ту же проблему для изменяемых объектов я не знаю.
...
Рейтинг: 0 / 0
31.10.2010, 01:44
| Ответить | Цитировать | Написать  
Выгоды контрактного программирования (design by contract)
    #36929563
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
я все сразу не могу делать.
Дальнейшее обсуждение продолжается в
/topic/802380&pg=-1

чтобы критерий подставновки не утонул в ерунде
...
Рейтинг: 0 / 0
31.10.2010, 01:52
| Ответить | Цитировать | Написать  
232 сообщений из 232, показаны все 10 страниц
  все  
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Выгоды контрактного программирования (design by contract)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=16&tid=1343356]:
 0ms
get settings:
 7ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 204ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 154ms
get tp. blocked users:
 1ms
others: 260ms
total:  659ms
созд. / загр.: 659ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]