powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Выгоды контрактного программирования (design by contract)
25 сообщений из 232, страница 7 из 10
Выгоды контрактного программирования (design by contract)
    #36921768
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНа месте прямоугольника, квадрат работает точь-в-точь как прямоугольник
это главный принцип. принцип подстановки Лисков
ой. не верю.
не правда. это не тот принцип.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36921769
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychназови его makeRectangle()
зачем называть makeRectangle, если программист посмотрит на сигнатуру и увидит, что возвращается прямоугольник.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36921770
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
к матам только не переходите.
а я пойду поработаю
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36921771
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizавторНа месте прямоугольника, квадрат работает точь-в-точь как прямоугольник
это главный принцип. принцип подстановки Лисков
ой. не верю.
не правда. это не тот принцип.

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

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


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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
class Rectangle {
	double w,h;
public:
	Rectangle(double iw, double ih) {
		w = iw;
		h = ih;
	}
	Rectangle setWidth(double newW) {
		return Rectangle(newW, h);
	}
	Rectangle setHeight(double newH) {
		return Rectangle(w, newH);
	}
	double getWidth() {
		return w;
	}
	double getHeight() {
		return h;
	}
	double getSpace() {
		return w*h;
	}
};
class Square: public Rectangle {
public:	
	Square(double side) : Rectangle(side, side){}
	Square setSide(double newSide) {
		return Square( newSide );
	}

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


 

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

	


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

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

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

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

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

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


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

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

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

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

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

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

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

я к тому, что имена операций деления и возведения в степень отличаются от целочисленных аналогов.
...
Рейтинг: 0 / 0
25 сообщений из 232, страница 7 из 10
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Выгоды контрактного программирования (design by contract)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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