powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
76 сообщений из 76, показаны все 4 страниц
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36929562
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNtchingiz,

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

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

моим решением, является иерархия представленная выше, но у нее есть огромный недостаток - неизменяемость данных. как решить ту же проблему для изменяемых объектов я не знаю.
/topic/800476&pg=7#9681990
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36929564
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNegorych
PS используя его технику легко отнаследовать квадрат от круга, например.. Но это же абсурд


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

Моя техника базировалась на том, что квадрат всегда является прямоугольником, наоборот уже не верно.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36929565
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
во первых, почему в твоем коде функции showШото не засунуты в свой класс под именем show?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
    void showRectangle(Rectangle r) {
		std::cout << "Rectangle(" << r.getWidth() << "," << r.getHeight() << ")" << std::endl;
	}

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


...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36929634
Зимаргл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ну сколько раз по одному месту на стене....

Где аксиоматика классов? Нет аксиоматики - нет контрактов и нет программы.
Контракт - это описаниие кто и что обязуется выполнить.

ЗЫ. Сижу на горе с ноутбуком =)

ЗЫ2. Мультик был советский - два чела смотрят с разных сторон на предмет:
1й - круг!!!
2й - квадрат!!!
....
А предмет - цилиндр.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36929823
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizво первых, почему в твоем коде функции showШото не засунуты в свой класс под именем show?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
    void showRectangle(Rectangle r) {
		std::cout << "Rectangle(" << r.getWidth() << "," << r.getHeight() << ")" << std::endl;
	}

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




в моем случае эти функции не принадлежат типу, а используют его.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36930234
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
с восстановлением ребенка, который делает вид, что он родитель к ребенку мы уже разобрались?
/topic/800476&pg=3#9674202
в исходном принципе действительно не заметно.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36930246
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
                таблица названий аксиом


            setWidth    setHeight  .  Rectangle
getWidth    gw_sw       gw_sh      .  gw_r
getHeight   gh_sw       gh_sh      .  gh_r
....................................         
getSpace    gs_sw       gs_sh         gs_r
                                    



...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36930259
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а, getSpace выводится из двух других, для нее не нужна специальная аксиоматизация


Код: plaintext
1.
2.
3.
4.
5.
            setWidth    setHeight  .  Rectangle
getWidth    gw_sw       gw_sh      .  gw_r
getHeight   gh_sw       gh_sh      .  gh_r
....................................         
getSpace                        
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36930262
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Аксиоматика для Мартина
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
scheme Rectangle =  class
    type                        
      Figure
     ,UReal  =  {| r: Real :- r >  0 . 0  |}  
    value
      setWidth  : Figure >< UReal -> Figure   
     ,setHeight : Figure >< UReal -> Figure   
     ,getWidth  : Figure          -> UReal      
     ,getHeight : Figure          -> UReal      
    axiom
      [gw_sw]          
        all w: UReal, f: Figure:- getWidth(setWidth(f, w)) = w
     ,[gw_sh]
        all h: UReal, f: Figure:- getWidth(setHeight(f, h)) = getWidth(f)
     ,[gh_sh]          
        all h: UReal, f: Figure:- getHeight(setHeight(f, h)) = h
     ,[gh_sw]
        all w: UReal, f: Figure:- getHeight(setWidth(f, w)) = getHeight(f)
  end





Расширили аксиоматикой для ЗБотана
Код: 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.
/*
                таблица названий аксиом


            setWidth    setHeight  .  Rectangle
getWidth    gw_sw       gw_sh      .  gw_r
getHeight   gh_sw       gh_sh      .  gh_r
....................................         
getSpace                        

*/

Rectangle

scheme ZBRectangle = extend  Rectangle with class
    value
      getSpace  : Figure          -> UReal  
     ,Rectangle : UReal >< UReal  -> Figure

    axiom
      [gw_r ]
        all w:UReal, h:UReal :-  getWidth(Rectangle(w,h)) = w
     ,[gh_r ]
        all w:UReal, h:UReal :-  getHeight(Rectangle(w,h)) = h
     ,[gspace ]          
        all f:Figure         :-  getSpace(f) = getHeight(f)*getWidth(f)

  end

...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36930270
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
ZBRectangle

scheme ZBSquare =  extend  ZBRectangle with class
    value
      Square    : UReal           -> Figure   
     ,setSide   : Figure >< UReal -> Figure   
    axiom
      [square]          
        all side: UReal             :- Square(side)           = Rectangle(side, side)
     ,[setSide]
        all newSide: UReal, f:Figure:- setSide(f, newSide) = Square(newSide)
  end
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36930288
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
где отличия от Мартина?

его первый пример, чуть переделанный под функциональный стиль. воид заменил на тип
Код: plaintext
1.
2.
3.
4.
5.
Rectangle * f (Rectangle * r)
{
   r->setWidth( 32 );
   return r;
}

использование в фукнциональном стиле

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
schema ZBSUsage  = class
 value
    f : Figure -> Figure   
    f( f)             is setWidth(r, 32 )

   ,isSquare : Figure -> Bool
/*  isSquare ((w,h))       is  if w           = h               then true else false end */

    isSquare (f)          is  if getWidth(f) = getHeight(f)  then true else false end


   ,squareAfterF: Figure -> Bool
    squareAfterF (fi)               is  isSquare(f(fi))

end



вызов

squareAfterF(Square(5)) выдаст false -- получился не Square, предполагаемый (но пока формально не введенный )инвариант нарушен.
Чего добились?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36930293
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
для фукнционального стиля без переменных) это требование
авторВ цепочке должно быть два преобразования

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

выглядит так
Код: plaintext
1.
2.
3.
4.
5.
6.
/*
         newRebenok : X-> Rebenok;
         rebenokMetod: Rebenok >< Z -> Rebenok;
         roditelMetod : Roditel >< Y -> Roditel;
 
*/
   rebenokMetod(roditelMetod(newRebenok(x),y), z);
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36931759
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz,

Это что за язык?

Тяжеловато читается, в общем понятно, но надо бы синтаксис.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36932114
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Introduction to RAISE
Chris George
March 2002

http://agp1.hx0.ru/arts/report249.pdf

Алгебраическое проектирование класса

http://www.softcraft.ru/design/classdesign/
авторКурс «Формальная спецификация и верификация программ» 2010-2011 уч.г.


2010 | 2009 | 2008

Лекторы: проф., доктор физ.-мат. наук Петренко А. К., канд. физ.-мат. наук Хорошилов А. В.
Продолжительность: 36 часов лекции, 36 часов семинары, 72 часа самостоятельная работа.
Аудитория: студенты 5 курса кафедр СП, АСВК и АЯ.
Лекции по средам на первой паре (8:45 - 10:30) в аудитории П-8.

http://sp.cmc.msu.ru/courses/fmsp/
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36935779
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz,

Нет, я не готов на такие жертвы - столько читать из чистой computer science ради квадратосрача (
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36936032
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargltchingiz,

Нет, я не готов на такие жертвы - столько читать из чистой computer science ради квадратосрача (

"квадрат/прямоугольник" - это только образец.
а проблема такого рода встречается часто.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36937015
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargl,

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

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

ZyK_BotaN так мы с функциональным стилем покончили? или так написать наследование
прямоугольников из квадратов?

покончили, и наследования не надо.
меня интересует альтернативное решение(ф-му решению с наследованием), решение проблемы с выполнением контракта, что у прямоугольника, передаваемого в качестве параметра, все стороны равны.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36937451
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizкстати, императивную часть и параметризацию схем в рсл не зачем читать для аксиом.

ZyK_BotaN так мы с функциональным стилем покончили? или так написать наследование
прямоугольников из квадратов?
Граждане а как это у вас квадрат наследовал прямоугольник. Сам по себе класс прямоугольника прекрасно выполняет функции квадрата. Наследование обычно идет в сторону расширения возможностей, тоесть прямоугольник может расширить квадрат.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36937467
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
обоже
))
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36937562
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudio,
Точно, я уже предлагал к солдатикам перейти.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36937772
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglrstudio,
Точно, я уже предлагал к солдатикам перейти.

ну зачем так сложно для чингиза.
Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36937855
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudio
Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла
какая ф-я принимающая целые числа не может принимать ноль?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36937997
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNrstudio
Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла
какая ф-я принимающая целые числа не может принимать ноль?

а какая ф-я принимающая прямоугольник не может принимать квадрат ?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938078
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNкакая ф-я принимающая целые числа не может принимать ноль?деление? ;-))
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938274
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudioZyK_BotaNrstudio
Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла
какая ф-я принимающая целые числа не может принимать ноль?

а какая ф-я принимающая прямоугольник не может принимать квадрат ?

вот и я о том же.

мой вопрос возник в связи с этой фразой :
rstudioа потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла
и "прямоугольник с квадратом" здесь не причем.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938349
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudioZyK_BotaNrstudio
Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла
какая ф-я принимающая целые числа не может принимать ноль?

а какая ф-я принимающая прямоугольник не может принимать квадрат ?
для юмористов
Код: plaintext
1.
2.
3.
4.
5.
void LSPV(Rectangle& r){
  r.SetWidth( 5 );
  r.SetHeight( 4 );
  assert(r.GetWidth() * r.GetHeight()) ==  20 );
}
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938362
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychZyK_BotaNкакая ф-я принимающая целые числа не может принимать ноль?деление? ;-))

в случае целых все будет ок?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938374
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNв случае целых все будет ок?если в качестве делимого будет не ноль? - конечно. А что, есть сомнения в этом? ))
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938413
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizrstudioZyK_BotaNrstudio
Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла
какая ф-я принимающая целые числа не может принимать ноль?

а какая ф-я принимающая прямоугольник не может принимать квадрат ?
для юмористов
Код: plaintext
1.
2.
3.
4.
5.
void LSPV(Rectangle& r){
  r.SetWidth( 5 );
  r.SetHeight( 4 );
  assert(r.GetWidth() * r.GetHeight()) ==  20 );
}


Опять у когото потеют ладошки пронаследовать квадрат от прямоугольника.
Я же выше сказал что прямоугольник не может быть базовым классом для квадрата. Что же он делает в параметрах твоей функции ? Там должен торчать нормальный базовый класс.

вот так вот другое дело
Код: plaintext
1.
2.
3.
void LSPV(Square& r){
  r.SetWidth( 5 );
}
[/quot]
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938418
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но вообще проблемы ООП прекрасно понимаю

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

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

ZyK_BotaN так мы с функциональным стилем покончили? или так написать наследование
прямоугольников из квадратов?

покончили, и наследования не надо.
меня интересует альтернативное решение(ф-му решению с наследованием), решение проблемы с выполнением контракта, что у прямоугольника, передаваемого в качестве параметра, все стороны равны.
вот аксиоматика для обоих типов.
http://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=-1#9543464
аксиома из версии Ректангле
Код: plaintext
1.
2.
3.
  ,[gw_sh]
   all h: UReal, f: Figure:-
            GetWidth(SetHeight(f, h)) = GetWidth(f)
означает незасимость операций задать высоту и взять ширину.
чтобы не задал в высоте, взятие ширины работает одинаково.

аксиома из версии Сквере
Код: plaintext
1.
2.
  ,[gw_sh]
   all h: UReal, f: Figure:- GetWidth(SetHeight(f, h)) = h
 
означает зависимость взятия ширины от задания высоты.
Взять ширину вернет заданную высоту.
эти две аксиомы не совместимы в принципе
--
То есть, записав их вместе, получаем следующую аксиому:
Код: plaintext
1.
2.
3.
4.
   all h: UReal, f: Figure:-
            h =   GetWidth(SetHeight(f, h))   /\ 
                   GetWidth(SetHeight(f, h)) = GetWidth(f)

через приравнивание $GetWidth(SetHeight(f, h))$ получаем


Код: plaintext
1.
   all h: UReal, f: Figure :-  h  = GetWidth(f)

Возьмем в $UReal$ значение $w$, причем $w != h$, после этого, используя
аксиому $gw\_sw$, из любого $f$, у которого ширина была задана
равной $w$, то есть, равного $SetWidth(f1, w)$ извлечем это $w$
Код: plaintext
1.
      h =   GetWidth(f) = GetWidth(SetWidth(f1, w)) = w 
Противоречие. Это означает, что две различные версии аксиом $gw\_sh$ не могут
выполняться вместе.
Отсюда следует, что нет никакой возможности в принципе считать $Square$ подтипом $Rectangle$.
Так же как нельзя считать $Rectangle$ подтипом $Square$.

Можно считать их 'братьями', являющимися подтипом некоторого неполного, неоднозначного типа.
---------
раз под subtyping - выделение типа понимается добавление аксиомы в спецификацию,
то выбрасывание аксиомы из спецификации - это создание надтипа.
выбросив из спецификации противоречивые аксиомы получим тип
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
scheme RealDad =  class
    type                        
      Figure
     ,UReal  =  {| r: Real :- r >  0 . 0  |}  
    value
      SetWidth  : Figure >< UReal -> Figure   
     ,SetHeight : Figure >< UReal -> Figure   
     ,GetWidth  : Figure          -> UReal      
     ,GetHeight : Figure          -> UReal      
    axiom
      [gw_sw]          
        all w: UReal, f: Figure:- GetWidth(SetWidth(f, w)) = w
     ,[gh_sh]          
        all h: UReal, f: Figure:- GetHeight(SetHeight(f, h)) = h
  end

вот к нему можно преобразовывать и объекты Ректангла и объекты Сквере.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938442
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudiotchingizrstudioZyK_BotaNrstudio
Нужно ему предложить класс Ноль пронаследовать от класса ЦелыеЧисла, а потом сидеть и удивляться, а как это не все методы можно применить к классу Ноль, многие не имеют из них смысла
какая ф-я принимающая целые числа не может принимать ноль?

а какая ф-я принимающая прямоугольник не может принимать квадрат ?
для юмористов
Код: plaintext
1.
2.
3.
4.
5.
void LSPV(Rectangle& r){
  r.SetWidth( 5 );
  r.SetHeight( 4 );
  assert(r.GetWidth() * r.GetHeight()) ==  20 );
}


Опять у когото потеют ладошки пронаследовать квадрат от прямоугольника.
Я же выше сказал что прямоугольник не может быть базовым классом для квадрата. Что же он делает в параметрах твоей функции ? Там должен торчать нормальный базовый класс.

вот так вот другое дело
Код: plaintext
1.
2.
3.
void LSPV(Square& r){
  r.SetWidth( 5 );
}

0)
это был ответ на твой вопрос, какая функция не может принять. Вот приведенная
и не может принять.
1)
дла особо наблюдательных - может быть базовым классом
, ибо есть программа на с++ которая его так наследует.
2)
о нежелательности такой программы, лет 15 уже как сообщил Роберт Мартин
и это было до того, как ты сказал
Более того, многие прочитали его мнение.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938447
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychZyK_BotaNв случае целых все будет ок?если в качестве делимого будет не ноль? - конечно. А что, есть сомнения в этом? ))
к чему тогда было замечание про деление?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938449
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudio
Опять у когото потеют ладошки пронаследовать квадрат от прямоугольника.
Я же выше сказал что прямоугольник не может быть базовым классом для квадрата. Что же он делает в параметрах твоей функции ? Там должен торчать нормальный базовый класс.

вот так вот другое дело
Код: plaintext
1.
2.
3.
void LSPV(Square& r){
  r.SetWidth( 5 );
}

1
так вот такая функция, принимающая квадрат,
не будет принимать прямоугольник при динамическом связывании
Код: plaintext
1.
2.
3.
4.
5.
void LSPV(Square& r){
  r.SetWidth( 5 );
  r.SetHeight( 4 );
  assert(r.GetWidth() * r.GetHeight()) ==  16 );
}
2
во вторых,
при наследовании Ректангла от Сквере, просто нельзя подставлять
большую часть объектов от ребенка в переменные от родителя,
ибо у них изначально нарушен инвариант с равенством сторон
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938457
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz
0)
это был ответ на твой вопрос, какая функция не может принять. Вот приведенная
и не может принять.


Как же не может если может, чингиз, я тебя не узнаю.
Если на вход подадут ректенгл с одинаковыми сторонами, она что бросит эксепшин и свернется ?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938462
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz
1
так вот такая функция, принимающая квадрат,
не будет принимать прямоугольник при динамическом связывании
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
void LSPV(Square& r){
  r.SetWidth( 5 );
  r.SetHeight( 4 );
  assert(r.GetWidth() * r.GetHeight()) ==  16 );
}
[/quot]


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

[src]Square& r = new Square();
 r.SetWidth( 5 );
  r.SetHeight( 4 );

Разделяй что относится к квадрату, а что к ректенглу. У базового класса квадрат может быть определен только r.SetWidth(5). У ректенгла пронаследованого может быть определен еще r.SetHeight(4);. У куба SetLength и тд. Функционал наращиваем а не шпаклюем унивесальный базовый класс а у потомков только его подрезаем.

[src]
2
во вторых,
при наследовании Ректангла от Сквере, просто нельзя подставлять
большую часть объектов от ребенка в переменные от родителя,
ибо у них изначально нарушен инвариант с равенством сторон

Открой для себя виртуальные функции.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938463
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
с тегами чтото поломалось,

вот сообщение

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

[src]Square& r = new Square();
r.SetWidth(5);
r.SetHeight(4);

Разделяй что относится к квадрату, а что к ректенглу. У базового класса квадрат может быть определен только r.SetWidth(5). У ректенгла пронаследованого может быть определен еще r.SetHeight(4);. У куба SetLength и тд. Функционал наращиваем а не шпаклюем унивесальный базовый класс а у потомков только его подрезаем.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938467
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если бы ты читал, не только то, что ты пишешь, то уже знал бы,
что квадраты и прямоугольники уже написаны Мартином.
Обсуждаются трудности наследования на примере тех,
которые уже написаны.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938473
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторУ базового класса квадрат может быть определен только r.SetWidth(5). У ректенгла пронаследованого может быть определен еще r.SetHeight(4);

угу.
а у целых можно определить только сложение,
а у пронаследованных вещественных уже умножение ибо
автор"Функционал наращиваем, а не шпаклюем унивесальный базовый класс а у потомков только его подрезаем"
пысы
это был сарказм, если что
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938484
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizЕсли бы ты читал, не только то, что ты пишешь, то уже знал бы,
что квадраты и прямоугольники уже написаны Мартином.
Обсуждаются трудности наследования на примере тех,
которые уже написаны.

чтото я не понял, кто-то коряво написал а вы тут обсуждаете что с этим делать ?
Понятное дело - переписывать по нормальному.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938617
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudiotchingizЕсли бы ты читал, не только то, что ты пишешь, то уже знал бы,
что квадраты и прямоугольники уже написаны Мартином.
Обсуждаются трудности наследования на примере тех,
которые уже написаны.

чтото я не понял, кто-то коряво написал а вы тут обсуждаете что с этим делать ?
Понятное дело - переписывать по нормальному.начальный топик прочитай, в первом сообщении есть ссылка, а то выглядишь сейчас глуповато
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938618
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNк чему тогда было замечание про деление?там специально было отцитировано, к чему. Функция, принимающая целые, но не принимающая ноль - это деление. Что именно осталось не понятым?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938635
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudio
Граждане а как это у вас квадрат наследовал прямоугольник. Сам по себе класс прямоугольника прекрасно выполняет функции квадрата. Наследование обычно идет в сторону расширения возможностей, тоесть прямоугольник может расширить квадрат.

оффтопик

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

ссылка на лекцию Мейера, где
он наследовал квадраты от прямоугольников
http://www.intuit.ru/department/se/oopbases/14/1.html
и картинка (если кто читать не может)



наследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,
ибо прямоугольники не входят подмножеством во множество квадратов.
Только сумашедший начнет наследовать прямоугольники от квадратов.
(равно как и рациональные от целых )
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36938671
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizнаследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,ибо прямоугольники не входят подмножеством во множество квадратов.
Только сумашедший начнет наследовать прямоугольники от квадратов.
(равно как и рациональные от целых )
Не согласен.И Мейер об это не писал.

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

И то и то ослабляет инвариант.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939028
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz
наследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,
ибо прямоугольники не входят подмножеством во множество квадратов.
Только сумашедший начнет наследовать прямоугольники от квадратов.
(равно как и рациональные от целых )

Я чето не понял твой репертуар чингиз.
Ты говоришь что в теории от прямоугольника можно пронаследовать квадрат,
очевидно руководствуясь этой логикой от квадрата по логике пронаследуешь линию, а от линии точку ?Где такое пишут, дай почитать
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939051
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
От прамоугольника можно наследоваться квадрату: углы прямые. В качестве расширения добавляется ещё и свойство равенства сторон. Но не наоборот. Квадрат - по определению прамоугольник с равными сторонами. При чём здесь линия, у которой даже углов нет, не понятно.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939062
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeОт прамоугольника можно наследоваться квадрату: углы прямые. В качестве расширения добавляется ещё и свойство равенства сторон.

а ничо что тогда класс ректенгл у тебя будет абстрактным ?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939301
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargltchingizнаследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,ибо прямоугольники не входят подмножеством во множество квадратов.
Только сумашедший начнет наследовать прямоугольники от квадратов.
(равно как и рациональные от целых )
Не согласен.И Мейер об это не писал.

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

И то и то ослабляет инвариант.
в этом и проблема, что расслабляет, а должно быть наоборот.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939310
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudio
очевидно руководствуясь этой логикой от квадрата по логике пронаследуешь линию, а от линии точку ?Где такое пишут, дай почитать
неверная у тебя логика.

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

так понятно?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939316
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudioShSergeОт прамоугольника можно наследоваться квадрату: углы прямые. В качестве расширения добавляется ещё и свойство равенства сторон.

а ничо что тогда класс ректенгл у тебя будет абстрактным ?

вспомнилось
Дуг МакИлрой
Эти типы совсем не "абстрактные", они настолько же реальны, и int и float .
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939338
rstudio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNrstudio
очевидно руководствуясь этой логикой от квадрата по логике пронаследуешь линию, а от линии точку ?Где такое пишут, дай почитать
неверная у тебя логика.

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

так понятно?

Чтобы хранить базовый класс нужно 2х байт, чтобы хранить его наследника нужно Х байт, а чтобы хранить линию достаточно Х/2 байт. Чтобы хранить наследника линии, точку, нужны Х/4 байт.

Все сходится :)
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939344
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNSiemargltchingizнаследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,ибо прямоугольники не входят подмножеством во множество квадратов.
Только сумашедший начнет наследовать прямоугольники от квадратов.
(равно как и рациональные от целых )
Не согласен.И Мейер об это не писал.

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

И то и то ослабляет инвариант.
в этом и проблема, что расслабляет, а должно быть наоборот.
Примерчик для опровержения?

Now the rule for the preconditions and postconditions for derivatives, as stated by
Meyer3, is:
"...when redefining a routine [in a derivative], you may only replace its
precondition by a weaker one, and its postcondition by a stronger one."


In other words, when using an object through its base class interface, the user knows
only the preconditions and postconditions of the base class. Thus, derived objects must not
expect such users to obey preconditions that are stronger then those required by the base
class. That is, they must accept anything that the base class could accept. Also, derived
classes must conform to all the postconditions of the base. That is, their behaviors and outputs
must not violate any of the constraints established for the base class. Users of the base
class must not be confused by the output of the derived class.
Clearly, the postcondition of Square::SetWidth(double w) is weaker than
the postcondition of Rectangle::SetWidth(double w) above, since it does not
conform to the base class clause “(itsHeight == old.itsHeight)”. Thus,
Square::SetWidth(double w) violates the contract of the base class.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939360
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rstudioZyK_BotaNrstudio
очевидно руководствуясь этой логикой от квадрата по логике пронаследуешь линию, а от линии точку ?Где такое пишут, дай почитать
неверная у тебя логика.

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

так понятно?

Чтобы хранить базовый класс нужно 2х байт, чтобы хранить его наследника нужно Х байт, а чтобы хранить линию достаточно Х/2 байт. Чтобы хранить наследника линии, точку, нужны Х/4 байт.

Все сходится :)

нет не сходится. сколько хранится бай - не известно(инкапусаляция, одному разрабу известно как он реализовал данный тип).
главное интерфейс.
в моей реализации, для хранения квадрата были взяты те же 2х байта, что и для прямоугольника.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939426
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thingizВозьмем в $UReal$ значение $w$, причем $w != h$, после этого, используя
аксиому $gw\_sw$, из любого $f$, у которого ширина была задана
равной $w$, то есть, равного $SetWidth(f1, w)$ извлечем это $w$
h = GetWidth(f) = GetWidth(SetWidth(f1, w)) = w
Противоречие. Это означает, что две различные версии аксиом $gw\_sh$ не могут
выполняться вместе.
Отсюда следует, что нет никакой возможности в принципе считать $Square$ подтипом $Rectangle$.
Так же как нельзя считать $Rectangle$ подтипом $Square$.

Мне кажется, уважаемый Чингиз, что ты таки ошибаешься в двух местах:
1. Выделено красным. Из одной неверной предпосылки не следует ложность другой.
2. Не надо смешивать LSP и контракты Мейерса. Подтипы отностятся к LSP, но не к Мейерсу.

LSPWhat is wanted here is something like the following substitution property: If
for each object o1 of type S there is an object o2 of type T such that for all
programs P defined in terms of T, the behavior of P is unchanged when o1 is
substituted for o2 then S is a subtype of T.

P(T) .eq. P(S) when S.is subtype(T)

Что считать подтипом? Похоже, что производный класс всегда является подтипом.

И тогда нужно аккуратно совместить LSP, где утверждение про подтипы и - контракты, где про производные классы.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939517
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1)
иерархия типов определяется законами логики из заданных аксиом,
то есть, дана Богом и не может быть изменена.
2)
иерархия классов определятся произволом программиста,
и может быть перекручена, чуть ли не в произвольном порядке.
3)
соответствие иерархий выполняется тогда, когда
для каждой пары подкласс - надкласс спецификация подкласса
является подтипом спецификации надкласса.
4)
проверка типов в компиляторе гарантирует работу программы
только тогда, когда иерархия типов соответствует иерархии классов.
5)
принципы дизайна по контракту создают иерархии классов
соответствующие иерархиями типов.
точка.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939898
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglthingizВозьмем в $UReal$ значение $w$, причем $w != h$, после этого, используя
аксиому $gw\_sw$, из любого $f$, у которого ширина была задана
равной $w$, то есть, равного $SetWidth(f1, w)$ извлечем это $w$
h = GetWidth(f) = GetWidth(SetWidth(f1, w)) = w
Противоречие. Это означает, что две различные версии аксиом $gw\_sh$ не могут
выполняться вместе.
Отсюда следует, что нет никакой возможности в принципе считать $Square$ подтипом $Rectangle$.
Так же как нельзя считать $Rectangle$ подтипом $Square$.

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

это не посылки, это следствия из аксиом. Из одной аксиомы строится один класс,
из другой - второй. аксиомы не совместимы и равнозначны. Классы в этом смысле
одинаковы - значение переменной одного класса не может быть присвоено в переменную
другого и наоборот.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939899
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargl
Что считать подтипом? Похоже, что производный класс всегда является подтипом.

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

Принцип подстановки Лисков меня уже не волнует, у меня свой критерий, лучше есть.
http://www.sql.ru/forum/actualthread.aspx?tid=800476&pg=10#9707022
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939905
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizSiemarglпропущено...


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

это не посылки, это следствия из аксиом. Из одной аксиомы строится один класс,
из другой - второй. аксиомы не совместимы и равнозначны. Классы в этом смысле
одинаковы - значение переменной одного класса не может быть присвоено в переменную
другого и наоборот.
В твоих аксиомах противоречия для наследования прямоугольника от квадрата нет.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939914
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ладно, для прямоугольника я могу придумать опровержение. Программа, которая умеет работать с квадратами и полагается на равенство сторон, опрокинется если получит прямоугольник.

Остается второе утверждение: Наследовать рациональные от целых можно.

Что то мне кажется, что жестко подходя к принципам - невозможно вообще ничего отнаследовать )))
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939930
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglЧто то мне кажется, что жестко подходя к принципам - невозможно вообще ничего отнаследовать )))Нашел ответ у Александреску - базовый класс должен задавать настолько мягкие ограничения, насколько возможно.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36939937
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargltchingizнаследовать квадраты от прямоугольников это теоретически правильно. А наоборот - нет,ибо прямоугольники не входят подмножеством во множество квадратов.
Только сумашедший начнет наследовать прямоугольники от квадратов.
(равно как и рациональные от целых )
Не согласен.И Мейер об это не писал.

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

И то и то ослабляет инвариант.
Уговорили. И вправду чушь написал -)
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #36941474
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tchingizКлассы в этом смысле
одинаковы - значение переменной одного класса не может быть присвоено в переменную
другого и наоборот.
Переменной надтипа можно присвоить значение подтипа. При этом переменная должна изменить свой тип на подтип (т.е. тип объекта сохраняется). Наоборот нельзя - компилятор не пропустит.
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #37557731
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
аналогичный трехлетний окружностесрач на dxdy.ru

Эллипс и окружность: что от чего наследуется.

http://dxdy.ru/topic49360.html


Цитаты из Страуструпа и Дейта перепостил для надежности хранения
Joker_vDТак, прошу прощения. Страуструп придерживается несколько другой точки зрения:

For example, in Section 23.4.3.1 of his book The C++ Programming Language, 3rd edition (Addison-Wesley, 1997), page 703, Bjarne Stroustrup​ has this to say:

"For example, in mathematics a circle is a kind of an ellipse, but in most programs a circle should not be derived from an ellipse or an ellipse derived from a circle. The often-heard arguments “because that’s the way it is in mathematics” and “because the representation of a circle is a subset of that of an ellipse” are not conclusive and most often wrong. This is because for most programs, the key property of a circle is that it has a center and a fixed distance to its perimeter. All behavior of a circle (all operations) must maintain this property (invariant). On the other hand, an ellipse is characterized by two focal points that in many programs can be changed independently of each other. If those focal points coincide, the ellipse looks like a circle, but it is not a circle because its operations do not preserve the circle invariant. In most systems, this difference will be reflected by having a circle and an ellipse provide sets of operations that are not subsets of each other."

Он не одинок, есть полно статей, где проводится та же идея, что "окружность — не эллипс, квадрат — не прямоугольник". Например:

K. Baclawski, B. Indurkhya, “The Notion of Inheritance in Object-Oriented Programming” (CACM 37, No. 9, September 1994​)
J. Rumbaugh, “A Matter of Intent: How to Define Subclasses” (Journal of Object-Oriented Programming, September 1996)
R.C. Martin, “The Liskov Substitution Principle” (C++ Report, March 1996)


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



Joker_vD
Цитируя Дейта, "По моему мнению, любая модель наследования, в которой тип ОКРУЖНОСТЬ не является подтипом типа ЭЛЛИПС, вряд ли может считаться хорошей моделью действительности". И позже: "However, the fact remains that circles are ellipses in reality; if we choose not to regard them in that way in “our system,” then certainly the things that “our system” calls circles and ellipses differ in some rather important ways from circles and ellipses in the real world. Indeed, they simply aren’t circles and ellipses (by definition), at least as those constructs are conventionally defined and understood. [...] Note too that if “our system” includes “ellipses” that aren’t ellipses or “circles” that aren’t circles, then “our system” is likely to be seriously misunderstood, and possibly misapplied, both by our intended users and by people who might subsequently have to perform maintenance on the system. So if you really want to have a system that supports ellipse-like things that aren’t ellipses or circle-like things that aren’t circles, then I would suggest very strongly that—at the very least—you call those things something other than ellipses and circles."

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

У Дейта в "Date on Database: Writings 2000-2006" есть статья про модель наследования, так там он когда разбирает статью Лисков, все время сокрушается, что "объект" у нее означает и текущее значение переменной, и саму переменную, что так и не указаны отличия между "классом" и "типом" — или не сказано, что это синонимы, и т.п.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #37557738
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тут у меня единодушное мнение со Страуструпом - я тоже пытался говорить, что
класс RSquare не имеет ничего общего с квадратами из математики, поэтому аппеляция к
геометрическому смыслу бессмысленна.
Далее, Страуструп говорит о проектировании, что если надо спроектировать классы.
Я пытался решить чисто технический вопрос уже есть класс Rectangle и класс Square из статьи Мартина (и именно такие как у Мартина и никакие другие) и для них написано пять триллионов шесть миллиардов пятсот тридцать одна программа.
Что будет если наследовать один из другого?
Наследовать можно, но поскольку один из классов не является подтипом другого,
теряется проверка типов. Вместо переменной родителя можно подставить переменную ребенка - компилятор пропустит, а на шаге выполнения задача сбойнет.
--

заодно определения


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

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

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


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

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

Таким образом получаем, что с++ не вполне полиморфен.

последнее улучшение. ))

полиморфизм это свойство-средство языка позволяющее записывать корректные выражения для более чем одного типа (множества типов мощности больше один)
дословный перевод из Милнера - возможность трактовать некоторые термы, как принадлежащие многим различным типам.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #37559356
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
из работы
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #37559359
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
отдельное спасибо Максиму Талдыкину
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #37559364
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz,

да, но полиморфизм - полиморфизму рознь.

мы ведь про ad-hoc полиморфизм говорим?
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #37559371
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
когда я говорю специальный, я так и пишу специальный полиморфизм.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #37559375
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
частные случаи полиморфизма должны удовлетворять определению общего случая.
Как и частные случаи любого понятия должны удовлетворять определению общего случая того же понятия.
Например, квадрат частный случай прямоугольника, и квадрат удовлетворяет определению прямоугольника.
...
Рейтинг: 0 / 0
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #37699566
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вот на счет контрактов часто жалуются. а что толку от контрактов, если они не проверяются на практике.
дак вот, встретил на рсдн хороший пост:
http://rsdn.ru/forum/decl/4522924.flat.aspx

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

суть топика такова. параметризируем монаду двумя типами: пост- и пред- условиями.
что получаем на практике - проверку контракта в момент компиляции.

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

что нам предлагают современные языки(а вернее их библиотеки). если мы попытаемся писать в закрытый файл, то получим исключение в рантайме.
но параметризированные монады позволяют отловить данную ошибку - в момент компиляции.
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
    #38251148
Фотография skole
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я пишу постоянно на контрактах, делается это так, объявляешь интерфейс и передаешь в зависимые классы только тип. В результате каждый класс можно тестировать отдельно, дописываешь внизу тестовый метод и готово. Как результат, архитектура становится намного прозрачней и читабельной для других, в больших проектах и самому ориентироваться легче. Кроме того, использование контрактов открывает широкие возможности для атрибутов. Объявил атрибуты, если классы в разных либах, компилятор их объединит в общий тип, что позволяет тянуть схему выполнения не класс за классом, а в произвольном, нужном порядке, например, сначала в одном потоке вызывать код, а только потом уже поднимать форму совсем в другом потоке и передавать туда инфу. Достоинств много, всего сразу и не перечислишь.
...
Рейтинг: 0 / 0
76 сообщений из 76, показаны все 4 страниц
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Re: Выгоды контрактного программирования (design by contract) квадратосрач2 +
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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