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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

автор

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

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

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

Откуда: Новгород-Северский
Сообщений: 104078
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

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


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

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

Откуда:
Сообщений: 31974
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

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

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

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

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

Откуда: Новгород-Северский
Сообщений: 104078
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

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


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

Откуда: Новгород-Северский
Сообщений: 104078
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
Сообщений: 6067
ZyK_BotaN,

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

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

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

более, того как выяснено в
//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

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


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

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

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

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


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

я к тому, что имена операций деления и возведения в степень отличаются от целочисленных аналогов.
27 окт 10, 11:58    [9683521]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10   вперед  Ctrl      все
Все форумы / Программирование Ответить