. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
в языках с утиной типизацией смысла "крышевать" круг и прямоугольник под фигурой нет. в плюсах это дает возможность работать с кругом и прямоугольников в единообразной манере.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, monax, Вы писали:
M>Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
М>в языках с утиной типизацией смысла "крышевать" круг и прямоугольник под фигурой нет. в плюсах это дает возможность работать с кругом и прямоугольников в единообразной манере.
На самом деле если говорим именно про иерархию (а не про полиморфизм , то надо смотреть для чего мы эту иерархию строим.
Иерархию надо строить от в первую очередь от процессов, а не от данных.
. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
А для чего тебе иерархия? Для каких процессов? А то не понятно, важно, ли что квадрат частным случаем прямоугольника или важнее что он правильный многоугольник.
. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом.
Так прямо все же наверное не говорится, или я не увидел? Sinclair назвал абсурдом иерархию классов геометрических фигур, очевидно имея ввиду наследование квадрата от прямоугольника или круга от эллипса. Такое наследование действительно неверно, если только фигуры не предполагаются неизменяемыми. Наследование же круга или прямоугольника от фигуры имеет смысл, если фигура эта абстрактная. Этот случай рассматривает Страуструп в своей книге, и оно как бы ничего, но рассматривает он его на первых же страницах, что создает впечатление, что наследовать реализацию нужно постоянно и ежедневно, чем поколения ООП-программистов продолжают заниматься уже лет двадцать. На мой взгляд пришла пора завязывать с этим делом, и по-моему проще объявить ООП устаревшим унылым дерьмом чем пытаться заниматься изменением его определения. Но видимо психологически это трудно, поэтому подход изменения определения того, что мы понимаем под ООП, пока побеждает.
Здравствуйте, Ведмедь, Вы писали:
В>Здравствуйте, мыщъх, Вы писали:
М>>в языках с утиной типизацией смысла "крышевать" круг и прямоугольник под фигурой нет. в плюсах это дает возможность работать с кругом и прямоугольников в единообразной манере.
В>На самом деле если говорим именно про иерархию (а не про полиморфизм , то надо смотреть для чего мы эту иерархию строим. В>Иерархию надо строить от в первую очередь от процессов, а не от данных.
давайте рассмотрим две модели.
первая:
obj_1 = new Figure(Triangle, positions);
obj_2 = new Figure(Pentagon, positions);
...
obj_x = new Figure(Shroom, positions);
и вторая:
Figure — базовый класс,
Triangle,Pentagon,,, -- производные
первая модель, очевидно, проще. вторая модель испытывает большие проблемы с тем, что оставить в базовом класс, а что вынести в производные. скажем, Move для всех фигур реализуется одинаково, а вот вычисление площади у каждой фигуры свое. в первой модели все методы в одном классе и через switch легко группировать родственные фигуры в местах их родства. скажем, если у нас есть функция для вычисления площади N-угольника, то она будет работать для всех фигур, кроме круга. во второй модели в этом смысле жопа полная.
кстати, если реализовать круг как многоугольник, то достаточно одного класса "многоугольник" и никакой иерархии вообще не нужно.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, Ведмедь, Вы писали:
В>>Здравствуйте, мыщъх, Вы писали:
М>>>в языках с утиной типизацией смысла "крышевать" круг и прямоугольник под фигурой нет. в плюсах это дает возможность работать с кругом и прямоугольников в единообразной манере.
М>кстати, если реализовать круг как многоугольник, то достаточно одного класса "многоугольник" и никакой иерархии вообще не нужно.
Повторюсь — надо смотреть какие задачи будут стоят перед иерархией (структурой классов). Я вообще последнее время наследованию реализации предпочитаю агрегацию
Здравствуйте, Ведмедь, Вы писали:
В>Здравствуйте, monax, Вы писали:
В>А для чего тебе иерархия? Для каких процессов? А то не понятно, важно, ли что квадрат частным случаем прямоугольника или важнее что он правильный многоугольник.
извините за глупость, но чем квадрат от прямоугольника отличается? геометрически тем, что квадрат задается меньшим кол-вом исходных данных. но вряд ли кто будет реализовывать изощренные способы задания квадрата и, скорее всего, функция потребует координат всех вершин. и в этом смысле квадрат все равно что треугольник.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, monax, Вы писали:
I> что создает впечатление, что наследовать реализацию нужно постоянно и ежедневно, I> чем поколения ООП-программистов продолжают заниматься уже лет двадцать.
без утиной типизации наследовать, действительно, придется.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
M>Если так, то как же правильно это делать?
В моем проекте все в географических координатах. И соответственно они оба Area заданная некоторым количеством точек и это правильно. Для пользователей это круг и квадрат. При смене проекции ну скажем на полярную это выглядит как хренькакаято некоторая область, хотя вояки все равно назовут это квадратом.
Рецепта нет единого и быть не может. Иногда да же важен не сам набор классов, а одинаковое понимание сущностей, которые они представляют всеми разработчиками проекта.
. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
Все просто, без определения ответсвенности или Responsibility фигур , ни о какой иерархии речи быть не может.
Здравствуйте, Ведмедь, Вы писали:
В>Здравствуйте, мыщъх, Вы писали:
М>>Здравствуйте, monax, Вы писали:
M>>>В начале было слово, и слово это было Что-то нетак с ООП
. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
М>>в языках с утиной типизацией смысла "крышевать" круг и прямоугольник под фигурой нет. в плюсах это дает возможность работать с кругом и прямоугольников в единообразной манере.
В>На самом деле если говорим именно про иерархию (а не про полиморфизм , то надо смотреть для чего мы эту иерархию строим. В>Иерархию надо строить от в первую очередь от процессов, а не от данных.
Хорошая мысль. Только почему именно процессы? Размышляя на эту тему я пришел к выводу что иерархии нет вообще в чистом виде. Кроме частного случая физического нахождения одного объекта в другом. Да и то его можно оспорить изменив систему координат. Иерархию объектов мы строим исходя из своего отношения к этим объектам. Отсюда следует что их (иерархий) может быть несколько. Это касается и каталога файлов и баз данных. Нет в принципе иерархических баз данных. И разумно строить несколько иерархий (или каталогов) на одно множество объектов. Объекты одного класса названы реляционной базой.. Ну что ж. Это частный случай. Потому я предлагал сделать несколько каталогов на винте. Т.е. одни и теже файлы можно собрать с каталогом своего отношения например к фильмам
1 первый каталог (любимые фильмы, фильмы для бабушкии т.д..).
2. Второй каталог по авторам
2. По жанрам.
и.т.д..
Форматирование в NTFS это позволяет делать.
В заключение скажу что название папок (уровней иерархий) не что иное как значение свойства либо самих объектов (например по цвету объекта), либо значение свойства которое приобретает объект будучи объединенный в множество. Например, значение свойства "любимый фильм" у объекта как такового нет. Но в группе объектов это свойство появляется.
М>>кстати, если реализовать круг как многоугольник, то достаточно одного класса "многоугольник" и никакой иерархии вообще не нужно. В>Повторюсь — надо смотреть какие задачи будут стоят перед иерархией (структурой классов). Я вообще последнее время наследованию реализации предпочитаю агрегацию
а я про что? геометрически круг и прямоугольник это фигуры. практически N-угольник сильно отличается от круга. и вы совершенно правильно говорите про задачи. может, нам нужна поддержка спрайтов.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
А иерархии нет там где ты ее не хочешь.. И есть там, где ты ее видишь
Здравствуйте, batu, Вы писали: B>В заключение скажу что название папок (уровней иерархий) не что иное как значение свойства либо самих объектов (например по цвету объекта), либо значение свойства которое приобретает объект будучи объединенный в множество. Например, значение свойства "любимый фильм" у объекта как такового нет. Но в группе объектов это свойство появляется.
Ну это вообще спорно, про свойство группы. У группы вообще нет свойств, они пу сути обобщение на будевые индикаторы, удовлетворяет ли объект условию вхождения в группу Y.
А иерархия как таковая существует как свойство принадлежности, и как уровень вложенности и как свойство "путь в иерархии"....
. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом.
I>Так прямо все же наверное не говорится, или я не увидел? Sinclair назвал абсурдом иерархию классов геометрических фигур
Может быть пора отлелить мух от котлет, и данные о фигурах от логики их рисования?
В принципе, базовый класс "Фигура" может быть заменён интерфейсом IDrawable?
А рисованием будет заниматься
В таком случае у нас может быть PrinteringRenderer, ScreenRenderer, да и FileWriter может реализовать IRenderer...
Проблема не в самом примере с фиграми, а том, что тогда ещё не было придумано отделять логику и данные от преставления. Вот скажем, чтобы круг нельзя было проткнуть треугоьником, а от прямоугольника всё отскакивало — это уже к фигурам имеет весьма отдалёное представление...
Здравствуйте, batu, Вы писали:
B>Здравствуйте, Ведмедь, Вы писали:
B> Отсюда следует что их (иерархий) может быть несколько.
наследовать можно больше чем от одного класса. замечательный способ сломать мозги.
давайте вот такой пример. рассмотрим базовые структуры данных -- списки и массивы. очевидно, что у обоих есть что-то общее (легко реализовать итератор), а есть и принципиальные различия -- у масива очень дешево брать индекс, а в список дешево вставлять элементы в произвольное место. это сильно влияет на применимость тех или иных алгоритмов сортировки.
таким образом -- местами со списком и массивом можно работать унифицированно и единообразно (например, вывод всех элементов). местами -- реализовывать функцию вставки в массив так же глупо как индексировать элементы списка.
вот вам и полиморфизм... с другой стороны, очень удобно, когда функция может принимать в качестве аргумента и массив, и список, и словарь, и даже дерево. так что полиморфизм все-таки рулит (хоть и без руля).
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, igna, Вы писали:
I>Так прямо все же наверное не говорится, или я не увидел? Sinclair назвал абсурдом иерархию классов геометрических фигур, очевидно имея ввиду наследование квадрата от прямоугольника или круга от эллипса. Такое наследование действительно неверно, если только фигуры не предполагаются неизменяемыми. Наследование же круга или прямоугольника от фигуры имеет смысл, если фигура эта абстрактная.
Sinclair
Например, очень много "учебников ООП" предлагают в качестве примера иерархии классов иерархию геометрических фигур. Опытным разработчикам понятно, что
а) в реальных программах так никто никогда не делает — требования к ним исключают использование иерархии фигур
б) получить математически корректную иерархию фигур вообще невозможно — гуглить срачи по "наследованию прямоугольника от квадрата"
igna
"Абсурд" этот ни в какую литературу по ООП не проник, он в ней был с самого начала, по крайней мере со времени популяризации C++. Не надо теперь делать вид, будто все было бы хорошо, если бы не некие абсурдописатели, иначе к последним нужно отнести самого Страуструпа, унаследовал же он Circle от Shape на первых же страницах своей The C++ Programming Language. Далее, Гослинг при разработке Java выкинул множественное наследование, но оставил наследование реализации очевидно отнюдь не считая последнее "редким частным случаем".
Sinclair
Я не понял. Вы с кем не согласны — со мной или со Страуструпом?
Вы что, серъёзно полагаете, что наследование Circle от Shape — хорошая, годная идея, которая может реально применяться в какой-то программе?
(из чего я могу заключить, что Sinclair не одобряет наследоване именно circle от shape)
У меня этот вопрос возник из-за того, что по работе часто приходится общаться с плюсами. Так то я пишу на питоне и мне никакие иерархии в пень не тарахтели, потому что ежели оно крякает, то это утка. А вот когда лезу в плюсы, то хочется понимать, какие идеи в плюсах лучше.
И собственно я ничего плохого в shape не вижу, если этот шейп будет определять общий интерфейс для геометрических фигур.
Здравствуйте, konstardiy, Вы писали:
K>Здравствуйте, batu, Вы писали: B>>В заключение скажу что название папок (уровней иерархий) не что иное как значение свойства либо самих объектов (например по цвету объекта), либо значение свойства которое приобретает объект будучи объединенный в множество. Например, значение свойства "любимый фильм" у объекта как такового нет. Но в группе объектов это свойство появляется. K>Ну это вообще спорно, про свойство группы. У группы вообще нет свойств, они пу сути обобщение на будевые индикаторы, удовлетворяет ли объект условию вхождения в группу Y. K>А иерархия как таковая существует как свойство принадлежности, и как уровень вложенности и как свойство "путь в иерархии"....
Вы не совсем внимательно прочитали. Я сказал что это не свойство группы, а значение нового свойства объекта возникающего при наличии этого объекта в группе определяя наше отношение к этому объекту в группе. Ну, нет у самого объекта "фильм" такого свойства "быть любимым". Оно появляется как наше отношение к фильму в группе объектов. Однако это может быть и значение существующего свойства объекта. Например, свойства цвет. Тогда мы разделим папки по значению этого свойства. Но всю иерархию мы вольны конструировать как нам вздумается.. Т.е. сначала по цветам обуви, потом по моделям, а потом по размерам. А можем и наоборот. Ни один из этих методов иерархии нельзя назвать более предпочтительным абсолютно. Они равноправны, если не применять сторонних критериев.
, то надо смотреть для чего мы эту иерархию строим.
