Здравствуйте, _nn_, Вы писали:
__>А чем так плохи неизменяемые объекты ?
Ничем не плохи. Я неизменностью прямоугольников в математике и изменяемостью их в большинстве реализаций в программировании объясняю, почему квадрат в математике является прямоугольником, а в программировании — чаще всего нет. (См. мое первое сообщение.
, где было в частности "отношение наследования, которое связывает квадрат и прямоугольник притянуто за уши и не имеет ни малейшего практического смысла", а потом все же унаследовал ISquare от IRectangle. Что, замена классов на интерфейсы оттянула отношение наследования от ушей обратно?
Здравствуйте, jedi, Вы писали:
J>Мне эти разговоры о наследовании квадрата от прямоугольника (или наоборот) всегда казались глупыми.
Спасибо, сознаю.
J>На самом деле это два разных типа, но: J>1) преобразование типа КВАДРАТ->ПРЯМОУГОЛЬНИК имеет смысл всегда; J>2) преобразование типа ПРЯМОУГОЛЬНИК->КВАДРАТ имеет смысл только когда ширина равна высоте.
КВАДРАТ и ПРЯМОУГОЛЬНИК связаны отношением IS, а это то отношение, которое чаще всего реализуют использованием наследования. Но в случае КВАДРАТа и ПРЯМОУГОЛЬНИКа оно редко проходит, вот я и ищу ответ, почему? Пока что предполагаю, что дело в изменяемости прямоугольников в программировании в отличие от их неизменяемости в математике.
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, _nn_, Вы писали:
__>>Можно изменять введя дополнительные интерфейсы IChangeRectange, IChangeSquare
A>... причем так, что IChangeSquare не является наследником IChangeRectangle, и наоборот.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, _nn_, Вы писали:
__>>А чем так плохи неизменяемые объекты ?
I>Ничем не плохи. Я неизменностью прямоугольников в математике и изменяемостью их в большинстве реализаций в программировании объясняю, почему квадрат в математике является прямоугольником, а в программировании — чаще всего нет. (См. мое первое сообщение.
, где было в частности "отношение наследования, которое связывает квадрат и прямоугольник притянуто за уши и не имеет ни малейшего практического смысла", а потом все же унаследовал ISquare от IRectangle. Что, замена классов на интерфейсы оттянула отношение наследования от ушей обратно?
Мое согласие было на предложение о контракте. Полное отрицание интерфейсов я не приводил.
Я привел пример решения через интерфейс или через контракт.
Лично мое мнение это конечно только интерфейсы без наследования реализацции. Практически это решение мне нравится.
Предложение контракта мне понравилось больше т.к. звучит более правильно теоретически. А вот как на практике это красиво сделать я не знаю.
С математической точки зрения r — квадрат. С точки зрения системы типов — нет.
Что касается поста VoidEx'а:
ИМХО, множество экземпляров базового класса и множество экземпляров наследника не пересекаются, однако множество ссылок/указателей на экземпляры базового класса содержит в себе множество ссылок/указателей на экземпляры производного
Здравствуйте, igna, Вы писали:
I>КВАДРАТ и ПРЯМОУГОЛЬНИК связаны отношением IS
Любой экземпляр типа short точно также является экземпляром типа long. Те short и long связаны отношением IS
Вообще то давно признано что ПО не обязано моделировать реальность 1 : 1. Нужно просто понять. что наследование — не более чем инструмент полезный в ряде случаев, но совершенно бесполезный и даже вредный в куче других. Случай квадрата и прямоугольника — четкий пример где наследование приходится притягивать за уши.
ME>С математической точки зрения r — квадрат. С точки зрения системы типов — нет.
А что, если класс Square не производить от класса Rectangle, то r сразу перестанет быть квадратом с математической точки зрения или станет им с точки зрения системы типов?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, jedi, Вы писали:
I>Это неправда. Вспомни про переполнение.
Это правда. Вспомни про операцию SetWidth (SetHeight). Если следовать твоей логике ("Вспомни про переполнение" (с)) — то квадрат не прямоугольник. А пару постов выше ты утверждал обратное. Будь последовательным
Здравствуйте, jedi, Вы писали:
J>Это правда. Вспомни про операцию SetWidth (SetHeight). Если следовать твоей логике ("Вспомни про переполнение" (с)) — то квадрат не прямоугольник. А пару постов выше ты утверждал обратное. Будь последовательным
Уфф.
1) У неизменного прямоугольника SetWidth не бывает.
2) short и long изменяемы.
3) Переполнение проявляет себя по разному даже у неизменных аналогов short и long.
Здравствуйте, Smal, Вы писали:
S>В общем-то бинарная операция по определению замкнутая (т.е. является отображением M x M -> M). Другими словами, деление на множестве натуральных чисел не бинарная операция
Интересно, а если результат операции в некоторых случаях не определен (как при делении на нуль), можно ли называть операцию бинарной?
Аналогично)
I>1) У неизменного прямоугольника SetWidth не бывает. I>2) short и long изменяемы.
Чем тип "прямоугольник" лучше (или хуже) типов short и long, что ему дана привилегия быть неизменяемым?
I>3) Переполнение проявляет себя по разному даже у неизменных аналогов short и long.
Что ты прицепились к переполнению? Это просто особенность реализации интегральных типов в современных процессоров. Я могу привести сотню похожих примеров без этой особенности, где наследование излишне, несмотря на точто отношение IS имеет место быть. Навскидку: окружность и эллипс, одномерный массив и массив размерности N (он является одномерным масивом элементы которого — массивы размерности N-1), файл и директория, изображение в формате BMP 8bpp и изображение в формате BMP 24bpp итд итп до бесконечности. Заметь, во всех случаях идет речь о связанных объектах, но это еще не значит что наследование уместно во вех случаях.
Я не спорю что неизменяемый квадрат является частным случаем неизменяемого прямоугольника, но наследование здесь совершенно бессмысленно.
В общем, спор этот бесполезен, ибо все эти аргументы уже миллион раз приводились. А воз все там
Так сам код в первом сообщении и есть этот пример. Зачем квадрату две стороны? Может, отнаследуем его еще от многоугольника?
Ответ с интерфейсами куда логичнее.
Здравствуйте, FDSC, Вы писали:
FDS>Вы сказали чушь откровенную. Настолько, что я так и не смог написать вам ответ с опровержением. Так что спасибо igna за то, что выразил мои мысли.
Все множество прямоугольников шире, чем множество квадратов, так что квадраты — это специализация прямоугольников (когда стороны равны), а вовсе не расширение, и наследование здесь ни при чем.
Здравствуйте, igna, Вы писали:
I>КВАДРАТ и ПРЯМОУГОЛЬНИК связаны отношением IS, а это то отношение, которое чаще всего реализуют использованием наследования. Но в случае КВАДРАТа и ПРЯМОУГОЛЬНИКа оно редко проходит, вот я и ищу ответ, почему? Пока что предполагаю, что дело в изменяемости прямоугольников в программировании в отличие от их неизменяемости в математике.
Наследованием реализуют обычно, если что-то связано _не только_ IS, но и EXTENDS. Не даром там такое слово.
Здравствуйте, jedi, Вы писали:
J>Я не спорю что неизменяемый квадрат является частным случаем неизменяемого прямоугольника, но наследование здесь совершенно бессмысленно.
У такого наследования нет никаких "подводных камней" в отличие от наследования в случае, когда фигуры изменяемы.
