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

Откуда: 010100
Сообщений: 6320
Обсуждение технологии. Зачем она нужна в практических применениях.
Описание тут
http://ru.wikipedia.org/wiki/Контрактное_программирование

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

Альтернативное мнение.
Гаджимурадов Рустам
P.S. Для несведущих - это всего лишь очередной лозунг.
Маркетинга там в разы больше, чем пользы. А в тех
случаях, когда это действительно нужно, оно, в общем-то,
применялось задолго до появления самого лозунга.
24 окт 10, 23:31    [9666338]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
Ну, Рустам мастер сам лозунгами бросаться.
В дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.
Потому, что сужается область определения функций SetWidth. Нарушается простое формальное правило.
А другие авторы, включая Роберта Мартина, нагоняют мистический ооп туман.


//https://www.sql.ru/forum/actualthread.aspx?bid=24&tid=756625&pg=5#9543547
//https://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=5#9590420

Сообщение было отредактировано: 24 окт 10, 23:56
24 окт 10, 23:50    [9666374]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
В дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.
25 окт 10, 11:51    [9668236]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
_мод
tchingiz
В дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.
так же как и подтип ромба. Так чего же выбрать?
25 окт 10, 12:05    [9668362]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
egorych
так же как и подтип ромба. Так чего же выбрать?

А не надо ничго выбирать. Просто методы ромба можно попытаться применить к квадрату.
25 окт 10, 12:56    [9668805]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
_мод
egorych
так же как и подтип ромба. Так чего же выбрать?

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

а нафига все эти нагромаждения?
нет никаких методов ни у ромба ни у квадрата ни какого то угольника
25 окт 10, 13:01    [9668852]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
_мод
tchingiz
В дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.
так же как и подтип ромба. Так чего же выбрать?

множественное наследование
25 окт 10, 13:40    [9669343]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
множественное наследование
это чтобы запутаться окончательно :-)) и ещё, до кучи, виртуально отнаследоваться от класса "четырёхугольники"
25 окт 10, 14:06    [9669648]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ViPRos
нет никаких методов ни у ромба ни у квадрата ни какого то угольника

Это верно. Есть процедуры/функции, у которых параметры имеют заданный тип (например прямоугольник). Их можно применять к подтипам (к квадратам), но с учетом инвариантов подтипа (равенство сторон).
25 окт 10, 14:15    [9669752]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
множественное наследование
это чтобы запутаться окончательно :-)) и ещё, до кучи, виртуально отнаследоваться от класса "четырёхугольники"

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

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

также при вызове конструктора Rectangle(w = 5, h = 5), будет создан прямоугольник, а не квадрат, аналогично тому что 1.0 - double, а не int.
25 окт 10, 14:16    [9669769]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
_мод
ViPRos
нет никаких методов ни у ромба ни у квадрата ни какого то угольника

Это верно. Есть процедуры/функции, у которых параметры имеют заданный тип (например прямоугольник). Их можно применять к подтипам (к квадратам), но с учетом инвариантов подтипа (равенство сторон).

если ввести понятия иммутабельности, то метод работающий с прямоугольником, не обязан знать о существовании типа квадрат, все по аналогии с примитивными типами double и int.
если в ф-ю корня передать целое число, то она вернет значиние типа double.
так и тут, если метод возвращает модифицированную фигуру(например увеличивает ширину в 2 раза), то никаких проблем не будет.
25 окт 10, 14:21    [9669814]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ZyK_BotaN
метод работающий с прямоугольником, не обязан знать о существовании типа квадрат

конечно, не обязан
ZyK_BotaN
если в ф-ю корня передать целое число, то она вернет значиние типа double.
так и тут, если метод возвращает модифицированную фигуру(например увеличивает ширину в 2 раза), то никаких проблем не будет.

Со значениями функций проблем нет - они возвращают заданный для них тип. Проблемы есть при передаче параметром подтипа вместо заданного типа - может сработать инвариант подтипа и процедура выдаст ошибку.
25 окт 10, 15:00    [9670269]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN,

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

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

Структура инвариантов должна идти строго параллельно со структурой наследования.
25 окт 10, 15:04    [9670315]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
_мод
Проблемы есть при передаче параметром подтипа вместо заданного типа - может сработать инвариант подтипа и процедура выдаст ошибку.

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

или я я заблуждаюсь? укажи мне пример, где будет ошибка.
25 окт 10, 15:06    [9670346]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

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

1. Это на уровне языка должно быть определено (забыл термин), что допускается возвращать наследников.
2. Если даже возвращается родительский тип, будет проверен инвариант этого типа. И ошибки не будет.

Если наследуются типы с инвариантами, проверяются все инварианты всех родителей. По очереди.
25 окт 10, 15:07    [9670365]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

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

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


ну у квадрата все стороны равны, какому из инвариантов прямоугольника это противоречит?
25 окт 10, 15:07    [9670374]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN,

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

А кто будет наследником у прямоугольника или ромба???
Тогда может и будет окончательный выбор.
25 окт 10, 15:18    [9670499]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

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

Siemargl

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

например квадрат.
25 окт 10, 15:21    [9670540]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN,

Я пример приводил, если квадрат - родитель. Ну я думаю, что идею пояснил.
25 окт 10, 15:43    [9670849]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ZyK_BotaN
я уже выше написал - решение неизменяемость объектов.

Это да. Только это уже чисто функциональное программирование.
25 окт 10, 16:01    [9671067]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

Я пример приводил, если квадрат - родитель. Ну я думаю, что идею пояснил.

а, тогда все ок.
квадрат ведь не родитель, а дочерний класс классов ромб и прямоугольник.
25 окт 10, 16:06    [9671137]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
Siemargl
Инварианты могут разными, в зависимости от задачи:
-вариант 1. Все стороны равны.
-вариант 2. Все углы прямые
-вариант 3. Сторон не больше 4х.
-вариант 4. Величины длины и ширины могут меняться независимо
25 окт 10, 16:26    [9671392]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

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

Где тут инвариант = условие для проверки?
25 окт 10, 16:31    [9671462]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
Siemargl
Где тут инвариант = условие для проверки?
ну да, не инвариант, но постусловие для соответстующего сеттера
-Изменение ширины не влияет на значение длины
-Изменение длины не влияет на значение ширины
их мы тоже в DbC надо проверять, кмк?
25 окт 10, 16:39    [9671558]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
egorych,

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

А инвариант - это корректность объекта в целом. Т.е. например, инвариантом может допускаться side effect, если после вызова объет остался верен инварианту, например квадратом (пусть и увеличенным вдвое).
25 окт 10, 16:45    [9671650]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
Siemargl
egorych,

Да. Но это чуть другое из DbC.
-Изменение ширины не влияет на значение длины - это отсутствие побочных эффектов.
в то время как у квадрата побочный эффект обязателен. Изменение "ширины" _должно_ приводить к изменению "длины" ( кавычки тут к тому, что у квадрата сложно выделить ширину и длину :) )
25 окт 10, 17:05    [9671966]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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


да.

SetWidth(Square(5), 10)
вернет значение
Rectangle(10, 5)
25 окт 10, 18:47    [9672897]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
SetWidth(Square(5), 10)
вернет значение
Rectangle(10, 5)
это смотря как реализована SetWidth(). Если, что логично, она будет спрашивать встроенный метод Rectangle.SetWidth(), то вернёт вполне себе квадрат ( 10, 10 ), иначе или SetWidth должна знать, кого ей передают, или реализация Square::SetWidth() должна быть очень необычна ( и нарушать принцип наименьшего удивления при этом )
25 окт 10, 19:57    [9673143]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
SetWidth(Square(5), 10)
вернет значение
Rectangle(10, 5)
это смотря как реализована SetWidth(). Если, что логично, она будет спрашивать встроенный метод Rectangle.SetWidth(), то вернёт вполне себе квадрат ( 10, 10 ), иначе или SetWidth должна знать, кого ей передают, или реализация Square::SetWidth() должна быть очень необычна ( и нарушать принцип наименьшего удивления при этом )

Ну вот код:

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)
25 окт 10, 20:24    [9673231]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
подправил класс Square:

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()+")");
	}
}

теперь программа:
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)
25 окт 10, 20:33    [9673258]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
_мод
tchingiz
В дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.

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

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

пысы.
поскольку сам Карделли разрешил использовать наивную модель памяти при толковании
ооп, в которой
обьект это пара (кортеж, множество_методов), то
моя функциональная запись классов и обьектов в виде
абстрактных автоматов оказывается точным описанием.
(класс это пара (множество_допустимых_значений, множество_функций),
объект - это пара (кортеж , множество_функций))
А проблема не возможности наследования остается все равно.
Так что функциональность тут не причем.
Дело в несовместимости аксиом описания классов, совмещением которых
и занят Мейер в своем методе программирования по контракту
25 окт 10, 21:15    [9673344]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
вот аксиомы обоих классов
https://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=4#9543464
25 окт 10, 21:18    [9673351]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Square s  = new Square( 5 );
Square evil = s.SetWidth( 10 ); // опа!
25 окт 10, 21:33    [9673385]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
tchingiz,

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

Если я понял правильно, то для решения проблем преобразования "родственников" есть виртуальные ф-ции. Инвариант ес-но, тоже должен быть виртуальным.
И еще мне кажется, что "теорию происхождения видов" неправильно привязывать к ООП - суть разная. (Майерса не читал, что он имел в виду - не знаю)
25 окт 10, 21:44    [9673419]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Square s  = new Square( 5 );
Square evil = s.SetWidth( 10 ); // опа!

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

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

что мне не нравится в моем коде, дак это метод show.
я его написал, что-бы короче было. лучше было бы написать два метода
showSquare и showRectangle
25 окт 10, 21:56    [9673446]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
Siemargl
tchingiz,

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

Если я понял правильно, то для решения проблем преобразования "родственников" есть виртуальные ф-ции. Инвариант ес-но, тоже должен быть виртуальным.
И еще мне кажется, что "теорию происхождения видов" неправильно привязывать к ООП - суть разная. (Майерса не читал, что он имел в виду - не знаю)

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

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

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

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

3
не Майерс, а Бертран Мейер.
25 окт 10, 22:10    [9673472]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
В результате клиент умирает от удивления, со словами: "а мы так не договаривались"
25 окт 10, 22:14    [9673482]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
Более того, точно такой же техникой на с++,
какой записывалось порождение квадратов из прямоугольников,
можно записать порождение прямоугольников из квадратов.
с точно той же проблемой не соответствия аксиом.
Эти классы не ребенок и родитель, а два близнеца.
Их не надо, вообще, один из другого порождать.
25 окт 10, 22:22    [9673499]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
belugin
Member

Откуда: Москва
Сообщений: 874
tchingiz,

как только ты делаешь квадрату setWidth он перестает быть квадратом. Надо просто в объектную модель ввести predicate classes как в языке cecil.
25 окт 10, 22:29    [9673516]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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


конечно, я это выше и продемонстрировал с примерами кода.
25 окт 10, 22:35    [9673535]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
под словом квадрат я не имею ввиду ничего другого кроме как
объекты обсуждаемого класса Square.
Они заданы однозначно и совершенно понятно формальным описанием
на с++ в примера Роберта Мартина.
После вызова функций setWidth из своего класса, квадрат квадратом быть не перестает.
Это переменная, объявленная классом, возможно, оказавшаяся в противоречивом состоянии..
И обсуждается смысл техники программирования,
а не смысл геометрических фигур на плоскости.
25 окт 10, 22:39    [9673549]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
под словом квадрат я не имею ввиду ничего другого кроме как
объекты обсуждаемого класса Square.
Они заданы однозначно и совершенно понятно формальным описанием
на с++ в примера Роберта Мартина.

а чем тебе не понравилась моя реализация фигур?
25 окт 10, 22:52    [9673599]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
а что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
25 окт 10, 23:17    [9673693]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
а что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?

если игнорировать метод show, то да.
25 окт 10, 23:25    [9673731]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
tchingiz,
Пока не прочитал статью Лисковой, не понятно было о чем вы говорите )

Теперь возвращаюсь к своему же предыдущему утверждению:
инварианты (аксиоматика) связана с наследованием, и обязательна к учитыванию при проектировании.
25 окт 10, 23:50    [9673844]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
естественно
26 окт 10, 00:44    [9674019]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
Статья не Лисков, а Мартина

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

Откуда:
Сообщений: 34544
ZyK_BotaN
tchingiz
а что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?

если игнорировать метод show, то да.

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


z -некоторый кортеж;
Square s = new Square(5);
Rectangle r = s;
s = r.method(z);

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

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

вот это главное,
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.
26 окт 10, 01:04    [9674060]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
ZyK_BotaN
tchingiz
а что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?

если игнорировать метод show, то да.

не понял, что да.

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

tchingiz

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


z -некоторый кортеж;
Square s = new Square(5);
Rectangle r = s;
s = r.method(z);

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


tchingiz

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

вот это главное,
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.

тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.
26 окт 10, 01:21    [9674088]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

вот это главное,
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.



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)); //явное преобразование вниз по иерархии
	}
}

вывод:

Rectangle(10.0,5.0)
Square(5.0)
26 окт 10, 01:28    [9674099]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
egorych
ZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Square s  = new Square( 5 );
Square evil = s.SetWidth( 10 ); // опа!

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

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

PS а мы даже ещё не добрались до ромба )))
26 окт 10, 01:46    [9674120]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
egorych
ZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Square s  = new Square( 5 );
Square evil = s.SetWidth( 10 ); // опа!

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

как это не должно?
метод setWidth возвращает Прямоугольник, а в исправленной версии появился метод квадрата setSide, пользуйся на здоровья и никаких ошибок.
egorych

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

PS а мы даже ещё не добрались до ромба )))

посмотри на 49-е сообщение. я там избавился от метода show, и теперь классы соответствуют принципу Лисков.
26 окт 10, 01:50    [9674121]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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


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


для работы с ромбом придется избавиться от Java. в ней нет множественного наследования.
26 окт 10, 01:54    [9674125]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
	public static void main(String[] args) {
		Square s = new Square(5);
		Rectangle r = s.setWidth(10);
		showRectangle(r);
		showSquare(new Square(r)); //явное преобразование вниз по иерархии
	}

блистательно! а теперь делаем:
Square s = new Square( 5 );
showRectangle( s );
showSquare( s.setWidth( 10 ) );
и, поскольку, оба класса у нас зачем-то родственники, получаем 2 неожиданных результата.
Предлагаю ещё один великолепный вариант окончательно запутать код:
showRectangle( Square( s.setWidth( 10 ) ) );
о! всё легально, всё компилируется, получается чушь )))
26 окт 10, 01:56    [9674128]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
посмотри на 49-е сообщение. я там избавился от метода show, и теперь классы соответствуют принципу Лисков.
посмотри лучше ты: для изменения размеров у Square и у Rectangle свои методы, для отображения у Square и Rectangle свои методы, в чём суть наследования теперь, можешь сказать? )))
26 окт 10, 02:01    [9674133]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

showSquare( s.setWidth( 10 ) );[/src]и, поскольку, оба класса у нас зачем-то родственники,

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

egorych

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

Привидение вниз по иерархии было введено по заявкам слушателей:
tchingiz

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

вот это главное,
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.

это я и сделал, изменил ширину, при этом произошла потеря точности.
но тут претензии не ко мне, этот метод был написан для tchingiz.
26 окт 10, 02:20    [9674150]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
посмотри на 49-е сообщение. я там избавился от метода show, и теперь классы соответствуют принципу Лисков.
посмотри лучше ты: для изменения размеров у Square и у Rectangle свои методы, для отображения у Square и Rectangle свои методы, в чём суть наследования теперь, можешь сказать? )))


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



а зачем еще наследование нужно?
26 окт 10, 02:23    [9674156]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

PS а мы даже ещё не добрались до ромба )))


#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;
}

выводит:
Rhomb(23,20)
Rhomb(90,5)
Rhomb(23,8)
Rhomb(90,9)
Rhomb(45,5)
Square(20)
26 окт 10, 02:50    [9674182]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

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

с потерей точности - да.
поэтому в жизни вещественные - целые ( целые - натуральне) есть,
а по принципу Лисков их нельзя преобразовать. Они - разные типы.
26 окт 10, 03:00    [9674189]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

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


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

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

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

должна быть изменена в


z -некоторый кортеж;
Square s = new Square(5);
Rectangle r = s;
s = r.method(z);

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

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

ребенок -> родитель,
изменение ребенка, под видом родителя ранее написанными программами
родитель -> ребенок

Сообщение было отредактировано: 26 окт 10, 03:14
26 окт 10, 03:05    [9674194]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

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

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


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

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

я тебе рассказывал, что оно неявно всплывает.
Оно всплывает у Мартина когда он рассматривает первый шаг -
после преобразования ребенка в родителя вызывает родительский метод.
Метод нарушает инвариант ребенка, что делает невозможным обратное преобразование в ребенка.
Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.
И вот это уже, приводит к тому, что портятся РАНЕЕ НАПИСАННЫЕ ПРОГРАММЫ.
Их писали в предположении аксиом родителя.
Дизайн по контракту выявляет эту не очевидную трудность -
подкласс - это не подтип. Нельзя подставлять переменные как Лисков хочет.
26 окт 10, 03:12    [9674198]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

должна быть изменена в


z -некоторый кортеж;
Square s = new Square(5);
Rectangle r = s;
s = r.method(z);

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

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

ребенок -> родитель,
изменение ребенка, под видом родителя ранее написанными программами
родитель -> ребенок

я допилил класс.
теперь можно это сделать так:
z -некоторый кортеж;
Square s = new Square(5);
Rectangle r = s;
s = new Square(r.method(z));
но, покажи мне, где требуется такое поведение в принципе лисков, что-бы результат метода объекта подтипа, возвращал объект подтипа, а не суперкласса. Можно сузить возвращаемый тип, но это не обязательно.

Сообщение было отредактировано: 26 окт 10, 03:30
26 окт 10, 03:13    [9674199]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

я тебе рассказывал, что оно неявно всплывает.
Оно всплывает у Мартина когда он рассматривает первый шаг -
после преобразования ребенка в родителя вызывает родительский метод.
Метод нарушает инвариант ребенка, что делает невозможным обратное преобразование в ребенка.
Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.
И вот это уже, приводит к тому, что портятся РАНЕЕ НАПИСАННЫЕ ПРОГРАММЫ.
Их писали в предположении аксиом родителя.
Дизайн по контракту выявляет эту не очевидную трудность -
подкласс - это не подтип. Нельзя подставлять переменные как Лисков хочет.


в моем случае не портятся.
вот старый код, в котором не знают о подтипе:
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);
	}

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

int _tmain(int argc, _TCHAR* argv[]){
	Square s = Square(5);
	showRectangle(foo(s));
	return 0;
}

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

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

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

Сообщение было отредактировано: 31 окт 10, 23:35
26 окт 10, 03:20    [9674202]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.

посмотри на пример написанный на с++. там нет ни одного виртуального метода.
26 окт 10, 03:21    [9674203]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
в принципе это не требуется,
это обычное требование к наследованию.
26 окт 10, 03:28    [9674205]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.

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

на какой пример?
26 окт 10, 03:29    [9674207]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
в принципе это не требуется,
это обычное требование к наследованию.

ты про динамическое связывание?
для для поддержки принципа Лисков оно и не нужно.
оно нужно для нарушения этого принципа.

tchingiz

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

где оно записано?
26 окт 10, 03:30    [9674208]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.

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

на какой пример?


https://www.sql.ru/forum/actualthread.aspx?tid=800476&pg=3#9674182
26 окт 10, 03:33    [9674210]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
автор
где оно записано?

тебе целую главу вытащить?
щас посмотрю.
в принципе лисков написано для любой ранее написанной программы (квантор всеобщности),
а не для конкретной.
Если ты хочешь доказать, что нет таких программ, которые зависнут, то надо их все перебрать.
щас посмотрю
26 окт 10, 03:37    [9674211]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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


зачем все.
ты мне дай 1 пример старой программы работающей с Прямоугольником, поведение которой измениться при передаче ей квадрата.
26 окт 10, 03:39    [9674216]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

Потом Мартин, чтобы победить эту проблему вызывает детский метод - динамическое связывание.
Заменяет функцию удовлетворяющую аксиомам родителя, на функцию удовлетворяющую аксиомам
ребенка.

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

посмотрел.
Ты находишься на шаге 1, после применения метода нельзя выполнить обратное
преобразование в квадрат.
и?
26 окт 10, 03:44    [9674217]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

посмотрел.
Ты находишься на шаге 1, после применения метода нельзя выполнить обратное
преобразование в квадрат.
и?[/quot]

дак старый код не знает о существовании квадрата. (там только ромбы и прямоугольники )
как поломается код?
26 окт 10, 03:47    [9674218]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544


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

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

но в моем ведь коде этой проблемы нет.
26 окт 10, 03:51    [9674222]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
вот так он поломался. Не код, а объект.
Был квадрат, а стороны стали разными.
теперь его нельзя назад преобразовать.
Почему Мартину это ясно, я не знаю. Это мистический ооп туман.
Если назад пробразовывать не надо - нет проблем.
26 окт 10, 03:51    [9674223]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

но в моем ведь коде этой проблемы нет.

из за этого
	showSquare(Square(rhomb));
?
так это явное преобразование любого кого попало в квадрат
26 окт 10, 03:54    [9674224]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
вот так он поломался. Не код, а объект.
Был квадрат, а стороны стали разными.
теперь его нельзя назад преобразовать.
Почему Мартину это ясно, я не знаю. Это мистический ооп туман.
Если назад пробразовывать не надо - нет проблем.


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

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

а если использовать изменяемые объекты и/или виртуальные методы, то принцип лисков будет нарушен.
26 окт 10, 03:55    [9674226]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

но в моем ведь коде этой проблемы нет.

из за этого
	showSquare(Square(rhomb));
?
так это явное преобразование любого кого попало в квадрат


это не старый код.
этот код новый, ведь мы уже знаем о типе Square и явно к нему приводим.
я добавил приведение только потому, что ты попросил.
можно удалить этот конструктор, и избавиться от проблемы.
26 окт 10, 03:56    [9674227]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
у тебя не ломается, потому что ты используешь явное преобразование.
Поэтому принцип Лисков и нафиг не нужен вообще.
можно строку в квадрат преобразовать.
26 окт 10, 03:57    [9674229]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
у тебя не ломается, потому что ты используешь явное преобразование.
Поэтому принцип Лисков и нафиг не нужен вообще.
можно строку в квадрат преобразовать.

если удалить этот конструктор, принцип нарушаться будет?
26 окт 10, 03:58    [9674232]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
пользователь может написать:

showSquare(Square(rhomb.getSide()));
и ничего не ломается, мы явно игнорируем угол.
26 окт 10, 04:03    [9674234]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
вот тут надо писать
int _tmain(int argc, _TCHAR* argv[])

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

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

void showSquare(Square s) {
		std::cout << "Square(" << s.getSide() << ")" << std::endl;
	}

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

Откуда:
Сообщений: 34544
ZyK_BotaN
пользователь может написать:

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


а это типа еще короче? чем?
showSquare(Square(rhomb));
26 окт 10, 04:19    [9674244]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
вот эти твои комбинации называны в шаго 0 анафемой програмирования.
    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;
	}


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

Откуда: 010100
Сообщений: 6320
ZyK_BotaN,

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

Если соблюсти DbC, то при работе программы правильно сформулированный инвариант родителя обломится, и ты узнаешь о проблеме.
26 окт 10, 09:34    [9674651]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN> class Square: public Rectangle, public Rhomb

странное наследование. Чего хотим получить, козловерблюда?
26 окт 10, 09:40    [9674707]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
методы работающие с прямоугольником могут работать и с квадратом, возвращая абсолютно идентичный результат(принцип Лисков).
это не правда, точнее, не вся правда. Правдой будет написать, что "методы, работающие с прямоугольником, будут скомпилированы и с квадратом, возвращая абсолютно непредсказуемый вариант". В пояснение простой пример: есть функция, которая вписывает произвольный прямоугольник в заданный и возвращает полученный прямоугольник. Я хочу ей воспользоваться, чтобы в заданный прямоугольник вписать квадрат, а потом дальше использовать его, как квадрат. Для пары Rectangle( 10, 2 ) + Square( 5 ) я получу правильный ответ, для пары Rectangle( 2, 10 ) + Square( 5 ) - неправильный.
26 окт 10, 09:45    [9674745]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
Siemargl
ZyK_BotaN,

У тебя нет клиента, полагающегося на аксиоматику базового класса.
у него нет ни одной проверки инвариантов ни для прямоугольника, ни для квадрата.
Хотим изменить сторону у квадрата, воспользовавшись функцией базового класса - "бам!" - на тебе произвольный прямоугольник, хотим сделать квадрат из прямоугольника 3х4 - "бам!" - на тебе квадрат 4х4! почему именно такой, почему не 3х3? - потому что гладиолус! какие уж тут "контракты" )))
26 окт 10, 09:56    [9674826]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
оказалось невозможное корректное выполнение цепочка
а) преобразование из ребенка в родителя
б) выполнение метода
в) восстановление ребенка взад.

А зачем делать а), если можно сразу сделать б) и не делать с)
Другое дело, что выполнение б) может нарушить инвариант ребенка и вызовет ошибку, так это нормальное поведение, так и д.б. Похоже, проблемы то и нет.
26 окт 10, 12:20    [9676436]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
(класс это пара (множество_допустимых_значений, множество_функций),

множество_допустимых_значений - это тип данных, а вот множество_функций - очень расплывчато. Я могу написать очень много функций, использующих этот тип данных в качестве парметров или значений, не включая их в класс. И что это будет ? Итак мы плавно возвращаемся к модульности в терминах АДы.
26 окт 10, 12:26    [9676485]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
вот аксиомы обоих классов
https://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=4#9543464

Просто для квадрата SetWidthe и SetHeight должны вызываться одновременно (как один оператор или транзакция) и с одной и то же величиной, чтобы не разрушить квадрат.
begin sq.SetWidthe(10),sq.SetHeight(10) end
begin sq.SetWidthe(5),sq.SetHeight(10) end  - а это ошибка
26 окт 10, 12:32    [9676538]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
Потом ты пишешь ребенка, херишь аксиомы родителя, и подсовываешь тем
программам, которые написаны в предположении похереных аксиом
ребенка под видом родителя.
В результате клиент умирает от удивления. Нарушен принцип подстановки Лисков.

аксиомы родителя полностью сохраняются, только дополняются аксиомами ребенка.
попытки применить методы родителя к ребенку никакого удивления вызывать не должны - ошибки ожидаемы и запрограммированы.
26 окт 10, 12:37    [9676586]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
вот тут надо писать
int _tmain(int argc, _TCHAR* argv[])

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

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

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


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

tchingiz

void showSquare(Square s) {
		std::cout << "Square(" << s.getSide() << ")" << std::endl;
	}

правильно?

да
26 окт 10, 13:00    [9676839]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
ZyK_BotaN
пользователь может написать:

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


а это типа еще короче? чем?
showSquare(Square(rhomb));

нет, просто можно обойтись и без приведения типов.
во втором случае нет неоднозначностей, мы явно игнорируем угол ромба.
в первом случае, перерасчет сторон квадрата не однозначен, ведь ф-я приведения может быть реализована по разному(например сохранять площадь фигуры).
26 окт 10, 13:02    [9676866]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
вот эти твои комбинации называны в шаго 0 анафемой програмирования.
    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;
	}


мы говорим о принципе Лисков?
значит этот принцип предан анафеме
как может выполняться принцип Лисков, если мы будем использовать виртуальные ф-и?
26 окт 10, 13:04    [9676893]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

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


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

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.
что я делаю не так?
26 окт 10, 13:17    [9677031]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
[quot Siemargl]ZyK_BotaN,

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


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

у базового класса Rhomb - есть ф-я изменения стороны и она работает коректно, гарантировано возвращая квадрат(так как угол тоно не измениться).
26 окт 10, 13:20    [9677057]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

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

вывод : 33.
что я делаю не так?

Ты код то покажи. Полный, где getSpace() описан.
26 окт 10, 13:40    [9677289]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
egorych
[quot Siemargl]ZyK_BotaN,

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

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

2. по остальным пунктам обвинения сказать определённо нечего, ась? ;-))
26 окт 10, 16:08    [9679067]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
Siemargl
ZyK_BotaN

вывод : 33.
что я делаю не так?

Ты код то покажи. Полный, где getSpace() описан.
да не, площади-то у прямоугольника и квадрата вычисляются одинаково ( width*height ), этот пример будет работать корректно, все косяки связаны с размерами.
26 окт 10, 16:11    [9679088]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

вывод : 33.
что я делаю не так?

Ты код то покажи. Полный, где getSpace() описан.


ага, забыл

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:	
	
	
};
26 окт 10, 18:23    [9680215]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
egorych
[quot Siemargl]ZyK_BotaN,

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


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


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


egorych

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

какой аксиоме?

egorych

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

не делай так.
egorych

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

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

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

а в паскале все ок. 1/2 = 0.5 и я с господином Виртом согласен.
26 окт 10, 18:30    [9680244]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

вывод : 33.
что я делаю не так?

Ты код то покажи. Полный, где getSpace() описан.
да не, площади-то у прямоугольника и квадрата вычисляются одинаково ( width*height ), этот пример будет работать корректно, все косяки связаны с размерами.


и я о том же. если сделать объекты фигур неизменяемые(частая практика: примитивные типы, строки) и не использовать виртуальных методов(они тогда не нунжны), то принцип Лисков нарушаться не будет.
26 окт 10, 18:32    [9680250]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN,

Ты чего то опять забыл. У тебя в Square неоднозначность вызова getSpace().
26 окт 10, 18:56    [9680374]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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


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

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

например ее используют в языке F#.
26 окт 10, 19:02    [9680420]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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


а ошибка у меня там математическая(в случае с ромбом), угол у меня храниться в градусах, а синус наверное ожидает радианы, но нашей дискуссии это не касается.
26 окт 10, 19:15    [9680504]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
начнём с конца

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

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

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

и ещё хочется услышать ответ на этот простой вопрос
egorych
хотим сделать квадрат из прямоугольника 3х4 - "бам!" - на тебе квадрат 4х4! почему именно такой, почему не 3х3?
на основании какой из аксиом квадрата, прямоугольника, или, не дай бог, ромба, следует, что квадрат конструируется из высоты прямоугольника?
26 окт 10, 20:29    [9680747]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
_мод
tchingiz
оказалось невозможное корректное выполнение цепочка
а) преобразование из ребенка в родителя
б) выполнение метода
в) восстановление ребенка взад.

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

а нужно сделать, чтобы передать ребенка в ранее написанные программы
для родителя
26 окт 10, 20:29    [9680750]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
ZyK_BotaN,
что ты делаешь с цитатами вечно?
задолбался править тебя.
сложи в зип весь код и прилепи сюда, а то не возможно бегать по постам
.
а нельзя его упростить, кстати. Хватит одного наследования для иллюстрации замечательной
мысли про неизменяемые объекты.
Лучше квадрат и прямоугольник оставить - меньше работать придется
26 окт 10, 20:33    [9680768]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
tchingiz
а нельзя его упростить, кстати. Хватит одного наследования для иллюстрации замечательной мысли про неизменяемые объекты.
Лучше квадрат и прямоугольник оставить - меньше работать придется
+1
26 окт 10, 20:35    [9680772]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

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

если при наследовании происходит уменьшение домена типа
например, как от вещественных к целым, или от целых к натуральным,
а меньшее множество обладает свойством идеала относительно операции,
скажем f : X >< X -> X, (где X домен родителя.
а Y домен ребенка, Y входит в X)
то есть, для любого x из X и y из Y f (y, x) попадает в Y,
то можно вызывать методы родителя сколько угодно.
26 окт 10, 20:39    [9680787]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
_мод
tchingiz
(класс это пара (множество_допустимых_значений, множество_функций),

множество_допустимых_значений - это тип данных, а вот множество_функций - очень расплывчато. Я могу написать очень много функций, использующих этот тип данных в качестве парметров или значений, не включая их в класс. И что это будет ? Итак мы плавно возвращаемся к модульности в терминах АДы.

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

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

Среди множества всех написанных функций, желательно выделить
подмножество таких, которые нельзя написать через другие, и их то и вносить
в класс. Судьба остальных зависит от произвола проектировщика
26 окт 10, 20:45    [9680810]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
egorych
на основании какой из аксиом квадрата, прямоугольника, или, не дай бог, ромба, следует, что квадрат конструируется из высоты прямоугольника?

а че не из площади или диагонали?
))
кста, если добавить аксиому к тем четырем, то это будет новый тип Square,
а не тот, с которого все началось.
26 окт 10, 20:50    [9680829]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN
Siemargl
ZyK_BotaN,

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


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

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

например ее используют в языке F#.

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

Но это наверное, уже оффтоп, не относящийся к правильному и тем более контрактному програмировнию ))))
26 окт 10, 22:25    [9681219]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
начнём с конца

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

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

egorych

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

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


egorych

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

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


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

egorych


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

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


egorych
хотим сделать квадрат из прямоугольника 3х4 - "бам!" - на тебе квадрат 4х4! почему именно такой, почему не 3х3?

здесь я с вами абсолютно согласен:
https://www.sql.ru/forum/actualthread.aspx?bid=24&tid=800476&pg=4#9674234
27 окт 10, 00:36    [9681785]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
методы работающие с прямоугольником могут работать и с квадратом, возвращая абсолютно идентичный результат(принцип Лисков).
это не правда, точнее, не вся правда. Правдой будет написать, что "методы, работающие с прямоугольником, будут скомпилированы и с квадратом, возвращая абсолютно непредсказуемый вариант". В пояснение простой пример: есть функция, которая вписывает произвольный прямоугольник в заданный и возвращает полученный прямоугольник. Я хочу ей воспользоваться, чтобы в заданный прямоугольник вписать квадрат, а потом дальше использовать его, как квадрат. Для пары Rectangle( 10, 2 ) + Square( 5 ) я получу правильный ответ, для пары Rectangle( 2, 10 ) + Square( 5 ) - неправильный.


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

egorych

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

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

вас не смущает что sin(1) - не целое? здесь аналогично.
вы понимаете что такое подтип? и что объект типа, не всегда можно без потери точности привести к подтипу?
27 окт 10, 00:42    [9681797]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
tchingiz
а нельзя его упростить, кстати. Хватит одного наследования для иллюстрации замечательной мысли про неизменяемые объекты.
Лучше квадрат и прямоугольник оставить - меньше работать придется
+1

что +1? а кто мне про ромб напомнил?
хорошо, ромб удалю.
27 окт 10, 00:44    [9681802]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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


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

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


а можно конкретней. покажи мне исправленный код?
что плохого в том, что явно задается имя класса где реализован метод?
27 окт 10, 00:47    [9681806]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
Более того, точно такой же техникой на с++,
какой записывалось порождение квадратов из прямоугольников,
можно записать порождение прямоугольников из квадратов.


нет, тогда код будет работать не корректно.
27 окт 10, 00:50    [9681814]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
egorych
на основании какой из аксиом квадрата, прямоугольника, или, не дай бог, ромба, следует, что квадрат конструируется из высоты прямоугольника?

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

не из площади ли диагонали потому, что это метод заказал ты, явно указал что нужно инорить ширину:

tchingiz

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

а мне это метод нафиг не надо. хорошо, выпилю.
27 окт 10, 00:52    [9681820]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
egorych
а потом дальше использовать его, как квадрат.
в этом ваша проблема.
вы хотите использовать результат ф-и работающей с прямоугольником в качестве квадрата
неа, это твоя проблема, потому что ты используешь наследование там, где оно противоречит всему, кроме одного утверждения: квадрат - это частный случай прямоугольника. Чтобы доказать обратное ты создал такое количество ограничений, что пользоваться иерархией и не породить ошибку стало практически не возможно. Пришлось даже отказаться от использования виртуальных методов и изменяющих методов класса, и, чтобы это не выглядело совсем глупонепрезентабельно, рассказываешь истории про пользу функционального стиля программирования и занимаешься софистикой.
27 окт 10, 01:10    [9681860]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
egorych
а потом дальше использовать его, как квадрат.
в этом ваша проблема.
вы хотите использовать результат ф-и работающей с прямоугольником в качестве квадрата
неа, это твоя проблема, потому что ты используешь наследование там, где оно противоречит всему, кроме одного утверждения: квадрат - это частный случай прямоугольника. Чтобы доказать обратное ты создал такое количество ограничений, что пользоваться иерархией и не породить ошибку стало практически не возможно. Пришлось даже отказаться от использования виртуальных методов и изменяющих методов класса, и, чтобы это не выглядело совсем глупонепрезентабельно, рассказываешь истории про пользу функционального стиля программирования и занимаешься софистикой.


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

вот пример иерархии типов хаскелла, в подтверждение что не только я считаю Целые подтипом Вещественных:
Картинка с другого сайта.
27 окт 10, 01:22    [9681879]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

я здесь имел ввиду иммутабельность и отсутствие виртуальных методов.
27 окт 10, 01:24    [9681882]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN:
>> ну и используйте в случае квадрата setSide,
допустим, у меня есть легаси-код, работающий с прямоугольниками и, раз квадрат - наследник его, то я хочу, чтобы он работал с квадратами. Корректно работал. Обычно у меня это получается, если иерархия наследования составлена верно. и не получается, когда приходится помнить "здесь читать, здесь не читать, здесь рыбу заворачивать".
>> а в случае int-а div.
сами вы используйте свой div, мне инта вполне достаточно. Если в паскале нужен дополнительный "совсем целочисленный" тип, то это его проблема. У меня в С++ всё работает, как надо.

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


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

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

ZyK_BotaN
egorych
хотим сделать квадрат из прямоугольника 3х4 - "бам!" - на тебе квадрат 4х4! почему именно такой, почему не 3х3?

здесь я с вами абсолютно согласен:
https://www.sql.ru/forum/actualthread.aspx?bid=24&tid=800476&pg=4#9674234
с чем согласен? это ведь ты этот метод породил, чтобы соблюсти формальное условие, наплевав на семантику обоих классов. И нечего на Чингиза пенять :))
Square( const Rectangle &parent )
{
   if( parent.getWidth() != parent.getHeight() )
      throw exception( "I can't construct Square from this Rectangle. sorry!" );

   _width = _height = parent.getWidth();
}
тоже не идеал
27 окт 10, 01:33    [9681895]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN:
>> ну и используйте в случае квадрата setSide,
допустим, у меня есть легаси-код, работающий с прямоугольниками и, раз квадрат - наследник его, то я хочу, чтобы он работал с квадратами. Корректно работал. Обычно у меня это получается, если иерархия наследования составлена верно. и не получается, когда приходится помнить "здесь читать, здесь не читать, здесь рыбу заворачивать".
>> а в случае int-а div.
сами вы используйте свой div, мне инта вполне достаточно. Если в паскале нужен дополнительный "совсем целочисленный" тип, то это его проблема. У меня в С++ всё работает, как надо.


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

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


egorych

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

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

egorych

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

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

egorych


Square( const Rectangle &parent )
{
   if( parent.getWidth() != parent.getHeight() )
      throw exception( "I can't construct Square from this Rectangle. sorry!" );

   _width = _height = parent.getWidth();
}
тоже не идеал

этот код, не только не идиал, но в отличии от моего порождает ошибку и не соответствует принципу подстановки Лисков.
27 окт 10, 01:41    [9681905]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
ты часто пользуешься такими объектами как : int, double, string?
ихнее поведение не отличается от моего.
у меня этих стрингов, как собак не резанных, в плюсах-то и у каждого - своё поведение А в сях так вообще строки нет, как таковой.
и int и double не порождают других типов при операциях с подобными себе, и это сильно отличается от представленного тобой

ЗЫ каламбур получился, кстати ))
ЗЫЫ за хаскель комментировать не буду, может оно там действительно надо
27 окт 10, 01:43    [9681908]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
ZyK_BotaN
процитируйте код, где квадрат превращается в прямоугольник.

если быть точнее, где он перестает быть квадратом.
ведь прямоугольником он является всегда.
27 окт 10, 01:44    [9681909]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

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

ты наверное про си, а в паскале и в делфе, операция еделения определена надо вещественными типами.

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

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

int, double и string я упомянул, что-бы оправдать иммутабельность.
27 окт 10, 01:49    [9681915]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
старый код будет работать с квадратом верно. я гарантирую это.
зря подписался. Возвращаемся к примеру: Есть функция, обрабатывающая прямоугольники
вписать один прямоугольник в другой
параметры: 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 ) - неправильный.
кроме того, я получу хороший оверхед на том, что постоянно буду конструировать объекты вместо того, чтобы их изменять, но это вопрос уже из другой песни, оставим его пока
27 окт 10, 02:01    [9681925]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
ZyK_BotaN
процитируйте код, где квадрат превращается в прямоугольник.

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

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

>> int, double и string я упомянул, что-бы оправдать иммутабельность.
тебе пришлось ввести иммутабельность, чтобы хоть как-то организовать наследование квадрата от прямоугольника, с изменяемыми объектами у тебя не выйдет ничего из этой затеи. Больше она низачем в данном случае, по крайней мере, не нужна. Это - факт! ))
27 окт 10, 02:09    [9681930]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

[/src]вполне себе бессмысленная функция. Теперь я туда подаю следующие пары:
- base - Rectangle( 10, 2 ), changed = Square( 5 ) и получу правильный ответ
- base = Rectangle( 2, 10 ), changed = Square( 5 ) - неправильный.
кроме того, я получу хороший оверхед на том, что постоянно буду конструировать объекты вместо того, чтобы их изменять, но это вопрос уже из другой песни, оставим его пока


	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);
27 окт 10, 02:10    [9681932]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
этот код, не только не идиал, но в отличии от моего порождает ошибку и не соответствует принципу подстановки Лисков.
зато он хотя бы пытается хоть как-то проверить соответствие входящих параметров контракту класса, а не лепит непойми что из непойми чего по дефолту.
27 окт 10, 02:15    [9681935]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
ZyK_BotaN
процитируйте код, где квадрат превращается в прямоугольник.

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

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

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

нет здесь динамической подмены квадрата прямоугольником, а вернее квадрат остался квадратом.
27 окт 10, 02:16    [9681936]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
этот код, не только не идиал, но в отличии от моего порождает ошибку и не соответствует принципу подстановки Лисков.
зато он хотя бы пытается хоть как-то проверить соответствие входящих параметров контракту класса, а не лепит непойми что из непойми чего по дефолту.

укажи мне, какой контракт мой код нарушает.
я привел реализацию ф-и в которой ты ожидал ошибку. где эта ошибка?
27 окт 10, 02:17    [9681937]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
результат:
Rectangle(5,2);
Rectangle(2,5);
ога, блестяще. Теперь приведи 2й результат к квадрату и во втором случае ты получишь квадрат 5*5 и скажи мне, можно вписать квадрат 5*5 в прямоугольник 2*10?
27 окт 10, 02:18    [9681939]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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


на счет оферхеда, во сколько раз размер прямоугольника превосходит тип double? я думаю раза в 2. и что это за липовый оверхед?
27 окт 10, 02:20    [9681942]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
результат:
Rectangle(5,2);
Rectangle(2,5);
ога, блестяще. Теперь приведи 2й результат к квадрату и во втором случае ты получишь квадрат 5*5 и скажи мне, можно вписать квадрат 5*5 в прямоугольник 2*10?


опять приведи к квадрату.
ты забыл о чем мы говорили?
мы говорили о старом коде который не знает о квадрате, и будет работать корректно.
27 окт 10, 02:21    [9681944]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
ZyK_BotaN
tchingiz
egorych
на основании какой из аксиом квадрата, прямоугольника, или, не дай бог, ромба, следует, что квадрат конструируется из высоты прямоугольника?

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

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

во первых, когда?
я про точное преобразование переживаю
27 окт 10, 02:21    [9681946]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
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
27 окт 10, 02:23    [9681948]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
мы берем метод setWidth, который возвращает прямоугольник основанный на объекте для которого его вызывают.
назови его makeRectangle() и вопросы уйдут. Если я работаю с только с квадратами, на кой хрен мне сдался прямоугольник??? и да, я понимаю, что код не скомпилится, и я буду долго ломать голову, почему, потом, наконец, залезу с исходник твоего класса, если он у меня есть, или напишу тучу unit-тестов, чтобы выяснить, как работает твой класс. В конце концов я его выкину из проекта, как никуда не годный, и напишу свой квадрат, который всегда будет квадратом, и всем потом расскажу, какой плохой ты мне подсунул класс квадрата ;-))
но зато твой класс выполняет принцип подстановки Лисков, это единственная положительная в нём черта, правда практическая ценность которой, мне, к примеру, совершенно не очевидна.
27 окт 10, 02:24    [9681949]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

я про точное преобразование переживаю

1)я же процитировал тебя.
2) для неизменяемых объектов это не требуется.
тот пример Милнера(или как его там) - доказал не состоятельность подхода при работе с изменяемыми объектами.
27 окт 10, 02:25    [9681950]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

если ты не хочешь работать с прямоугольником - не наследуй от него квадрат.
27 окт 10, 02:27    [9681952]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
egorych
ZyK_BotaN
результат:
Rectangle(5,2);
Rectangle(2,5);
ога, блестяще. Теперь приведи 2й результат к квадрату и во втором случае ты получишь квадрат 5*5 и скажи мне, можно вписать квадрат 5*5 в прямоугольник 2*10?


опять приведи к квадрату.
ты забыл о чем мы говорили?
мы говорили о старом коде который не знает о квадрате, и будет работать корректно.
и я об этом же. У меня есть квадрат и прямоугольник, мне нужно вписать в прямоугольник этот квадрат. И у меня есть функция, написанная для прямоугольников, логично ей воспользоваться, ты мне скажи? по мне, так логично. Берём, используем, всё компилируется, всё работает, и почти всегда корректно, за исключением некоторых данных, на которых результат получается неверным. Желаю приятных ночей в отладке такого бага )))
27 окт 10, 02:29    [9681956]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

тема началась с контрактов и подстановки Лисков.
я реализовал квадрат и прямоугольник, а вам не понравилось что он работает корректно.
вы все время хотите нарушить контракт.
27 окт 10, 02:29    [9681957]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
если ты не хочешь работать с прямоугольником - не наследуй от него квадрат.
Ес! Я тебе об том и говорю, что нельзя наследовать квадрат от прямоугольника, потому что это разные фигуры, с некоторыми похожими свойствами, не более того.
27 окт 10, 02:31    [9681961]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
автор

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


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

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

Более, того любой нормальное наследование которые вы делаете проходит по схеме увеличения домена класса.
Доменом класса было декартово произведение длиной n, наследовали класс с добавлением одного поля. Получили домен класса из декартового произведения длинной n+1

Сообщение было отредактировано: 27 окт 10, 02:35
27 окт 10, 02:33    [9681962]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
egorych

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

тема началась с контрактов и подстановки Лисков.
я реализовал квадрат и прямоугольник, а вам не понравилось что он работает корректно.
вы все время хотите нарушить контракт.
предыдущий абзац остался не прочитанным, штоле?
27 окт 10, 02:33    [9681963]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
egorych
ZyK_BotaN
результат:
Rectangle(5,2);
Rectangle(2,5);
ога, блестяще. Теперь приведи 2й результат к квадрату и во втором случае ты получишь квадрат 5*5 и скажи мне, можно вписать квадрат 5*5 в прямоугольник 2*10?


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


нет не логично.
у меня есть ф-я sin, я подставляю целое, а получаю в результате дробь.
здесь то же самое. пользуйся ф-й на здоровье, но она возвращает не квадрат а прямоугольник.
27 окт 10, 02:34    [9681964]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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


что-бы выяснить как работает мой класс нужно миниммум усилий. нет ни виртуальных ф-й, ни исключительных ситуаций.
На месте прямоугольника, квадрат работает точь-в-точь как прямоугольник. - это главный принцип. принцип подстановки Лисков.
а то что ты предложил ему противоречит.
27 окт 10, 02:37    [9681967]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
автор
На месте прямоугольника, квадрат работает точь-в-точь как прямоугольник
это главный принцип. принцип подстановки Лисков

ой. не верю.
не правда. это не тот принцип.
27 окт 10, 02:40    [9681968]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
назови его makeRectangle()

зачем называть makeRectangle, если программист посмотрит на сигнатуру и увидит, что возвращается прямоугольник.
27 окт 10, 02:40    [9681969]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
к матам только не переходите.
а я пойду поработаю
27 окт 10, 02:41    [9681970]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
автор
На месте прямоугольника, квадрат работает точь-в-точь как прямоугольник
это главный принцип. принцип подстановки Лисков

ой. не верю.
не правда. это не тот принцип.


тогда просвяти меня. я серьезно.
видимо я неправильно трактую этот принцип. но что характерно, в моей реализации он точно не нарушается.
27 окт 10, 02:41    [9681971]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN,
>>у меня есть ф-я sin, я подставляю целое, а получаю в результате дробь.
функция sin принимает значение типа double и возращает значение типа double, все знают, что такое синус, и все знают, как квадрат вписать в прямоугольник.

>>здесь то же самое. пользуйся ф-й на здоровье, но она возвращает не квадрат а прямоугольник.
ну чтож, дебаггер в зубы, и приятных ночей в отладке, чтобы понять, почему иногда квадрат в итоге получается нормальный, а иногда - нет.
вот если бы функция sin для некоторых целых чисел возвращала-бы мне значение, большее единицы, то я тогда бы с тобой согласился, что ситуация - нормальная, а мне просто не повезло, и надо написать ещё один синус, для целых
27 окт 10, 02:42    [9681972]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN,
>>у меня есть ф-я sin, я подставляю целое, а получаю в результате дробь.
функция sin принимает значение типа double и возращает значение типа double, все знают, что такое синус, и все знают, как квадрат вписать в прямоугольник.


великолепно
ф-я setWidth принимает(неявно) объект типа прямоугольник и возвращает прямоугольник.
27 окт 10, 02:43    [9681975]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
как еще?
во первых он написан не идеально.
Тем более, перевод.

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

автор

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

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

27 окт 10, 02:44    [9681977]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
tchingiz
как еще?
во первых он написан не идеально.
Тем более, перевод.

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

автор

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

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


тогда мой код удовлетворяет этому принципу.
при передаче параметра нет разници что мы напишем. Rectangle(5, 5) или Square(5), во втором случае 1-й конструктор будет вызван неявно.
27 окт 10, 02:46    [9681980]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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


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

в третьих, таки сделай отдельный код для квадратов и прямоугольников. поменьше что бы было.
я на выходных сделаю такой же наоборот, наследую прямоугольник из квадрата, в твоей манере
если пойму ее.
27 окт 10, 02:46    [9681981]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
ZyK_BotaN
tchingiz
как еще?
во первых он написан не идеально.
Тем более, перевод.

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

автор

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

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


тогда мой код удовлетворяет этому принципу.
при передаче параметра нет разници что мы напишем. Rectangle(5, 5) или Square(5), во втором случае 1-й конструктор будет вызван неявно.

может он у тебя и подтип
27 окт 10, 02:47    [9681982]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
ZyK_BotaN
На месте прямоугольника, квадрат работает точь-в-точь как прямоугольник. - это главный принцип. принцип подстановки Лисков.
а то что ты предложил ему противоречит.
если для соблюдения теоретических принципов мне приходится вводить дополнительные ограничения на использование моего кода, то это говорит о том, что есть ошибка в предположении, что этот принцип здесь применим, только и всего. Если есть контракт, что прямоугольник является квадратом тогда и только тогда, когда его высота равна ширине, то я не могу конструировать квадрат из прямоугольника произвольным образом, а _должен_ этот контракт проверить, понимаешь меня? Отсюда следует только один вывод - нельзя квадрат наследовать от прямоугольника, ибо это нарушает контракт класса и принцип подстановки Лисков.
27 окт 10, 02:52    [9681984]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
egorych,

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

ЗЫ спасибо за отличную беседу, кстати. Мне было интересно ))
27 окт 10, 02:56    [9681988]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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


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

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


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

+
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;
	}
	

	


я специально оставил ф-ю сумы полщадей, так как на ней, ИМХО, код и сломается
27 окт 10, 02:56    [9681990]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
egorych
ZyK_BotaN
На месте прямоугольника, квадрат работает точь-в-точь как прямоугольник. - это главный принцип. принцип подстановки Лисков.
а то что ты предложил ему противоречит.
если для соблюдения теоретических принципов мне приходится вводить дополнительные ограничения на использование моего кода, то это говорит о том, что есть ошибка в предположении, что этот принцип здесь применим, только и всего. Если есть контракт, что прямоугольник является квадратом тогда и только тогда, когда его высота равна ширине, то я не могу конструировать квадрат из прямоугольника произвольным образом, а _должен_ этот контракт проверить, понимаешь меня? Отсюда следует только один вывод - нельзя квадрат наследовать от прямоугольника, ибо это нарушает контракт класса и принцип подстановки Лисков.


если не соблюдать тер. принципы, то у нас вылезут ошибке.
мое мнение, принцип Лисков важен для понимания опасности наследования классов.
конечно, избегать изменяемое состояния и полный отказ от виртуальных методов - зло, но минимизировав их использования мы получаем более очевидный не подверженный ошибкам код.
27 окт 10, 03:00    [9681992]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

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


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

(pascal+haskel) vs (Cи)
ты же сишник?, я то предположил из-за того что для тебя нормально 1/2 = 0.
даже в 3-м питоне это исправили(или наоборот, я уже не помню).
27 окт 10, 03:07    [9681996]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
k0rvin
Member

Откуда:
Сообщений: 524
ZyK_BotaN
вот пример иерархии типов хаскелла, в подтверждение что не только я считаю Целые подтипом Вещественных:
Картинка с другого сайта.


это не иерархия типов, а иерархия классов типов и никаким подтипом Вещественных Целые в Хаскелле не являются.
27 окт 10, 08:14    [9682153]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN,

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

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

Откуда:
Сообщений: 34544
автор
Вещественных Целые в Хаскелле не являются.

более, того как выяснено в
//https://www.sql.ru/forum/actualthread.aspx?tid=795626&pg=1
и не могут являться.
так же как натуральные не подтип целых.
27 окт 10, 08:41    [9682223]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
а нужно сделать, чтобы передать ребенка в ранее написанные программы
для родителя

ранее написанные программы для родителя принимают тип ребенка без преобразования (или я что-то не понимаю ?).
27 окт 10, 09:35    [9682464]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
то можно вызывать методы родителя сколько угодно.

методы родителя к ребенку можно вызывать сколько угодно без всяких ЕСЛИ. Другое дело, что может быть отказ в их исполнении по аксиомам ребенка.
27 окт 10, 09:39    [9682489]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
я с твоего позволения буду называть множество_допустимых_значений
доменом типа, ибо тип - это спецификация класса, то есть, набор аксиом.

Так набор аксиом и определяет домен. И зачем вводить новые сущности :)
tchingiz
пиши функции, не включая в класс. Это будут функции не включенные в класс.

А зачем тогда класс вообще. Понятие модуль гораздо конструктивнее.
tchingiz

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

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

Нет, это ошибка проектирования ЯП. Добавление операции не расширяет тип.
int (+,-,*,div)
int c
с=1 div 2  - c=0
c=1/2  -  ошибка - справа float, слева int
c=int(1/2) - с=0
27 окт 10, 10:28    [9682824]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
tchingiz
присвоении t значения любой переменной s: S,

Любой нормальный компилятор обругает такое присваивание :) или хотя-бы предупредит
27 окт 10, 10:33    [9682864]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
Siemargl
ZyK_BotaN,
Мне лень листать, но по моему твой код работает верно,потому что в нем нет квадратов. Все неявно (конструкторами) преобразовывается в прямоугольники.


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

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

я так понял с ваших слов, что проблема моего кода в том, что он работает.
27 окт 10, 11:53    [9683469]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
k0rvin
[quot ZyK_BotaN]вот пример иерархии типов хаскелла, в подтверждение что не только я считаю Целые подтипом Вещественных:
это не иерархия типов, а иерархия классов типов и никаким подтипом Вещественных Целые в Хаскелле не являются.


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

я к тому, что имена операций деления и возведения в степень отличаются от целочисленных аналогов.
27 окт 10, 11:58    [9683521]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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


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

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


у меня они как раз открыты для расширения и закрыты для изменения. все ок. где нарушение?
27 окт 10, 12:02    [9683565]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
_мод
tchingiz
присвоении t значения любой переменной s: S,

Любой нормальный компилятор обругает такое присваивание :) или хотя-бы предупредит


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

Переменные ведь разных типов - компилятор предупредит (должен), что будет преобразование.
Плохое определение, вообщем.
27 окт 10, 12:34    [9683862]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
_мод
ZyK_BotaN
да нет, там вроде все нормально написано, и компиляторы вроде не ругаются.

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

как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
27 окт 10, 12:37    [9683886]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ZyK_BotaN
как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.

Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
27 окт 10, 12:42    [9683935]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

можешь назвать о компиляторах каких языков ты говоришь.
27 окт 10, 12:44    [9683953]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
Кстати, у Лисков правильно написано - не присвоение t=s, а подстановка вместо t s.
Т.е. методы t непосредственно применяются к s и при этом их поведение не меняется.
К случаю квадратов и прям-ов это полностью подходит, т.к. методы прям-ов на квадратах либо нормально работают, либо не работают совсем. Но поведение их не меняется.
зы Нужно делать, как в динамических языках - левая часть принимает тип правой. То же и при передаче парметров, т.е. в методы прям-ов передаются квадраты без преобразования типов.
27 окт 10, 13:08    [9684158]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ZyK_BotaN
можешь назвать о компиляторах каких языков ты говоришь.

Последний такой был pl/1. М.б. какой-нить паскаль. Но мне больше нравится подход в динамических языках: переменная принимает тип выражения из правой части.
27 окт 10, 13:23    [9684292]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
k0rvin
Member

Откуда:
Сообщений: 524
ZyK_BotaN
класс Integral является подтипом класса Real.

как это понимать?
"тип подтипом типа" понимаю,
"класс субклассом класса" понимаю,
"класс подтипом класса" не понимаю =/

ZyK_BotaN
или я что-то не понимаю?

скорее что-то путаешь.

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

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

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

это [почти] везде где так
27 окт 10, 13:31    [9684342]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

это [почти] везде где так

ну а я это указал для тех, для кого 1/2 = 0 - является интуитивно понятным.

k0rvin

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

виноват исправлюсь
27 окт 10, 17:14    [9686861]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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


но это ведь происходит без потери точности?
27 окт 10, 17:41    [9687178]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

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

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

пысы


Дмидек
Мемберы Siemargl и egorych добавлены в ЗПТ.
Чингиз - традиционный вопрос - ты им сообщишь при оказии или
мне написать письма ? :-)
27 окт 10, 20:03    [9687957]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

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

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

ZyK_BotaN, пример слишком тривиален (и дажи при том ты ромб выбросил, как неудобный=) и неопределены аксиомы, чтобы на нем тренировать.
27 окт 10, 20:18    [9688016]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544
не неудобный ромб, а мы его попросили, ато долго думать при длинном примере.
Его мысль все равно видна будет.
27 окт 10, 20:25    [9688039]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

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


двай, изобретай. но что за проблема с аксиомами.
и самое главное ты не ответил на вопрос про открытость/закрытость
27 окт 10, 20:27    [9688050]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN
и самое главное ты не ответил на вопрос про открытость/закрытость

Речь об этих классах.

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

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

Второе нарушение тут.
	Square(Rectangle r) : Rectangle(r.getHeight(),r.getHeight()),
		Rhomb(90, r.getHeight()) {

	}
	Square(Rhomb r) : Rectangle(r.getSide(),r.getSide()),
		Rhomb(90, r.getSide()) 
Появится еще одна фигура - тебе придется переписать и ее наследников по иерархии, чтобы учесть ее ньюансы.
27 окт 10, 20:55    [9688168]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
Siemargl
ZyK_BotaN
и самое главное ты не ответил на вопрос про открытость/закрытость

Речь об этих классах.

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

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

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

Siemargl

Второе нарушение тут.
	Square(Rectangle r) : Rectangle(r.getHeight(),r.getHeight()),
		Rhomb(90, r.getHeight()) {

	}
	Square(Rhomb r) : Rectangle(r.getSide(),r.getSide()),
		Rhomb(90, r.getSide()) 
Появится еще одна фигура - тебе придется переписать и ее наследников по иерархии, чтобы учесть ее ньюансы.


зачем? разве в принципе о/з сказано про то что можно изменять супер классы?
я лишь увидел что можно расширять наследников и запрещено ломать родительские классы.
27 окт 10, 22:13    [9688486]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN,

1. Мне кажется, что ты неверно понимаешь иммутабельность.
2. Иммутабельность часто неудобна в реальной работе, чтобы на ней ставить икону. Кроме того, в С++ иммутабельности нет и в Java вроде бы тоже. (Она есть в D - и если поискать - можно найти статью Брайта, где поясняется отличие C++ const от D immutable)
3. Второе нарушение не относится к принципу о/з.
27 окт 10, 22:29    [9688571]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
Я придумал пример. Геймдев, RTS.
Владелец - поле боя.
Класс 1. Статический тайл. Контракт - всегда валиден.
Класс 2. Динамический тайл. Может быть разрушен. Контракт - не разрушен.
Класс 3. NPC. Может быть заморожен. Контракт - не заморожен.
Класс 4. User's soldier. Может управляться человеком. Контракт - жив, бегает.
27 окт 10, 22:41    [9688642]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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


в джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.
а в с++ можно все .
27 окт 10, 22:51    [9688691]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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


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

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

Siemargl

3. Второе нарушение не относится к принципу о/з.

можно на пальцах?
27 окт 10, 22:54    [9688707]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6320
ZyK_BotaN, давай про солдатиков придумывай.

Кстати, вспомнил историю из геймдева. Когда игра падала - потому что для свиньи вызывался метод "стрелять", а пистолета - то нету )
27 окт 10, 23:07    [9688746]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

Siemargl

3. Второе нарушение не относится к принципу о/з.

можно на пальцах?

а точнее, если не относится к принципу о/з то в чем проблема?
имхо, это не нормально добавлять в иерархию наследования класс, и хотеть, что-бы наследники об этом не знали.
27 окт 10, 23:08    [9688751]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 107759
Siemargl
ZyK_BotaN, давай про солдатиков придумывай.

Кстати, вспомнил историю из геймдева. Когда игра падала - потому что для свиньи вызывался метод "стрелять", а пистолета - то нету )

блицкриг?
там еще есть байка:
отнаследовали ракету от летающего аппарата.
и в плохую погоду ракета возвращалась на базу
27 окт 10, 23:09    [9688758]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4765
Дмидек
Мемберы Siemargl и egorych добавлены в ЗПТ.
сэнкс, тронут ;-))
28 окт 10, 01:38    [9689317]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

для классического примера Мартина я их записал.

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

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

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

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

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

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

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

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

К сообщению приложен файл. Размер - 0Kb


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

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

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

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

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

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


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


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

p: POLYGON; r: RECTANGLE; t: TRIANGLE


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


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


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

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


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

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

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



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

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


здесь В - ребенок, А - родитель, статическое связывание - ранне связывание == вызов метода родителя

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


и как это мне поможет?
если на то пошло, то я могу точку от квадрата отнаследовать , но не квадрат от круга
30 окт 10, 18:36    [9706081]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ViPRos
Member

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

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

Откуда:
Сообщений: 34544
это не топология, а теория категорий.






пысы
ну, у Сибилева и ЛаТех, шоб он был здоров.
Поехать мозгом можно, пока нарисуешь

Сообщение было отредактировано: 31 окт 10, 00:50
31 окт 10, 00:39    [9706902]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 34544


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

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

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

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

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

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

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

тип 3 не является подтипом 2.
тип 5 не является подтипом 4
31 окт 10, 01:29    [9706997]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

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

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

на этой радостной ноте пишем обобщение принципа подстановки Лисков
до критерия подстановки



автор


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



Сообщение было отредактировано: 31 окт 10, 01:41
31 окт 10, 01:37    [9707022]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

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

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

ZyK_BotaN

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

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

Откуда:
Сообщений: 34544
я все сразу не могу делать.
Дальнейшее обсуждение продолжается в
https://www.sql.ru/forum/actualthread.aspx?bid=24&tid=802380&pg=-1

чтобы критерий подставновки не утонул в ерунде

Сообщение было отредактировано: 31 окт 10, 01:53
31 окт 10, 01:52    [9707059]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10      [все]
Все форумы / Программирование Ответить