ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Выгоды контрактного программирования (design by contract)
25 сообщений из 232, страница 4 из 10
  4  все
Выгоды контрактного программирования (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
| Ответить | Цитировать | Написать  
25 сообщений из 232, страница 4 из 10
  4  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Выгоды контрактного программирования (design by contract)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=16&msg=36919584&tid=1343356]:
 0ms
get settings:
 12ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 208ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 70ms
get tp. blocked users:
 1ms
others: 244ms
total:  569ms
созд. / загр.: 569ms
x
x
Закрыть


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