Иерархия геометрических фигур - Философия программирования

Здравствуйте, monax, Вы писали:

M>Так то я пишу на питоне и мне никакие иерархии в пень не тарахтели, потому что ежели оно крякает, то это утка.

Это иллюзия, а не утка.
Не надо путать утиную типизацию "если крякает, то утка" с той ее аппроксимацией, что мы имеем в ЯП: "Если есть метод крякать(), то утка".
В формулировке утиной типизации делается упор на поведение объекта, а не на просто наличие метода с определенным именем, который может делать что угодно.
Потому что название метода не дает никаких гарантий, что нечто в результате крякнет, как утка, а не крякнет сайт какой-нть.
В приципе, то же применимо к наследованих, но там в явной форме есть принцип подстановки Лисков, о котором почему-то никто в утиной типизации не упоминает, а зря, ибо он там точно так же применим и его требования должны выполняться.

Здравствуйте, monax, Вы писали:

M>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

Имхо, в этих дебатах жизненная рутина расставила всё по местам: хрен с той абстрактной наукой, ОПП банально не удобно на практике. Пусть реализован проект, где прямоугольник наследован от фигуры. Погода изменилась, на арену выходят квадраты. Куда их лепить? Наследовать от прямоугольника? Тогда есть шанс в объектах иметь лишнее поле — размер одной из сторон, необходимо перекрывать методы и следить за тем, чтобы длины сторон были одинаковы. Наследовать прямоугольник от квадрата? Или, как нас учат, нужно делать новую абстракцию для "всяких-угольников"? Иными словами — получи по башке рефакторингом, именно РЕфакторингом, т.е. переделкой уже реализованного функционала, а не просто добавление нового.
А как решать расширение функционала уже имеющейся иерархии классов, особенно внешних, т.е. где модификация невозможна?
Напр., Implicit-выкрутасы в Scale — та ещё хрень.

Если я не ошибаюсь, то автор STL в С++ категорически против классовой иерархии. В ФЯ свои вещи изначально назвали своими именами: основная цель ОПП — повторное использование кода, вот там и решают эти проблемы на уровне кода через полиморфные функции — если функция использует какие-то операции над объектом, то ей нужна только гарантия того, что такая операция определена, а как объект устроен — ее не касается. Поэтому в алгебраических типах иерархией не страдают. Новые языки, например, Go, Clojure и пр. не пошли по стопам С++, и не просто так (хотя в той же кложуре классы есть, но фактически для соседства с жабой).

Здравствуйте, monax, Вы писали:

M>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

Все просто, без определения ответсвенности или Responsibility фигур , ни о какой иерархии речи быть не может.

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

Здравствуйте, monax, Вы писали:

M> Если так, то как же правильно это делать?

Если подходить к вопросу глобально — написание софта надо начинать не с копанием вопросов "кого от чего будем наследовать", а с выяснения требований. Вот значит правильно — сесть и выяснить требования.

Здравствуйте, Ведмедь, Вы писали:

В>Здравствуйте, мыщъх, Вы писали:

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

В>На самом деле если говорим именно про иерархию (а не про полиморфизм

, то надо смотреть для чего мы эту иерархию строим.
В>Иерархию надо строить от в первую очередь от процессов, а не от данных.
давайте рассмотрим две модели.
первая:
obj_1 = new Figure(Triangle, positions);
obj_2 = new Figure(Pentagon, positions);
...
obj_x = new Figure(Shroom, positions);

и вторая:
Figure — базовый класс,
Triangle,Pentagon,,, -- производные

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

кстати, если реализовать круг как многоугольник, то достаточно одного класса "многоугольник" и никакой иерархии вообще не нужно.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, batu, Вы писали:

М>давайте вот такой пример. рассмотрим базовые структуры данных -- списки и массивы. очевидно, что у обоих есть что-то общее (легко реализовать итератор), а есть и принципиальные различия -- у масива очень дешево брать индекс, а в список дешево вставлять элементы в произвольное место. это сильно влияет на применимость тех или иных алгоритмов сортировки.

М>таким образом -- местами со списком и массивом можно работать унифицированно и единообразно (например, вывод всех элементов). местами -- реализовывать функцию вставки в массив так же глупо как индексировать элементы списка.
Кстати, в Вашем примере списки и стеки легко (и правильно) наследуются от массива.

Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, monax, Вы писали:

M>> Если так, то как же правильно это делать?

K>Если подходить к вопросу глобально — написание софта надо начинать не с копанием вопросов "кого от чего будем наследовать", а с выяснения требований. Вот значит правильно — сесть и выяснить требования.

То есть в итоге с описания процессов

И от процессов будем думать архитектуру, доменную модель, а потом иерархию классов

Которая кстати в общем случае не совпадет топологически с доменной моделью

Здравствуйте, monax, Вы писали:

M>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

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

Здравствуйте, monax, Вы писали:

M>Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

Как правильно делать ЧТО именно? Примеры?

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, monax, Вы писали:

M>>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

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

На самом деле если говорим именно про иерархию (а не про полиморфизм

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

Здравствуйте, monax, Вы писали:

M>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

А для чего тебе иерархия? Для каких процессов? А то не понятно, важно, ли что квадрат частным случаем прямоугольника или важнее что он правильный многоугольник.

В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

Здравствуйте, monax, Вы писали:

M>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом.

Так прямо все же наверное не говорится, или я не увидел? Sinclair назвал абсурдом иерархию классов геометрических фигур, очевидно имея ввиду наследование квадрата от прямоугольника или круга от эллипса. Такое наследование действительно неверно, если только фигуры не предполагаются неизменяемыми. Наследование же круга или прямоугольника от фигуры имеет смысл, если фигура эта абстрактная. Этот случай рассматривает Страуструп в своей книге, и оно как бы ничего, но рассматривает он его на первых же страницах, что создает впечатление, что наследовать реализацию нужно постоянно и ежедневно, чем поколения ООП-программистов продолжают заниматься уже лет двадцать. На мой взгляд пришла пора завязывать с этим делом, и по-моему проще объявить ООП устаревшим унылым дерьмом чем пытаться заниматься изменением его определения. Но видимо психологически это трудно, поэтому подход изменения определения того, что мы понимаем под ООП, пока побеждает.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Ведмедь, Вы писали:

В>>Здравствуйте, мыщъх, Вы писали:

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

М>кстати, если реализовать круг как многоугольник, то достаточно одного класса "многоугольник" и никакой иерархии вообще не нужно.

Повторюсь — надо смотреть какие задачи будут стоят перед иерархией (структурой классов). Я вообще последнее время наследованию реализации предпочитаю агрегацию

Здравствуйте, Ведмедь, Вы писали:

В>Здравствуйте, monax, Вы писали:

В>А для чего тебе иерархия? Для каких процессов? А то не понятно, важно, ли что квадрат частным случаем прямоугольника или важнее что он правильный многоугольник.
извините за глупость, но чем квадрат от прямоугольника отличается? геометрически тем, что квадрат задается меньшим кол-вом исходных данных. но вряд ли кто будет реализовывать изощренные способы задания квадрата и, скорее всего, функция потребует координат всех вершин. и в этом смысле квадрат все равно что треугольник.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, monax, Вы писали:

I> что создает впечатление, что наследовать реализацию нужно постоянно и ежедневно,
I> чем поколения ООП-программистов продолжают заниматься уже лет двадцать.
без утиной типизации наследовать, действительно, придется.

M>Если так, то как же правильно это делать?
В моем проекте все в географических координатах. И соответственно они оба Area заданная некоторым количеством точек и это правильно. Для пользователей это круг и квадрат. При смене проекции ну скажем на полярную это выглядит как ~~хренькакаято~~ некоторая область, хотя вояки все равно назовут это квадратом.
Рецепта нет единого и быть не может. Иногда да же важен не сам набор классов, а одинаковое понимание сущностей, которые они представляют всеми разработчиками проекта.

Здравствуйте, Ведмедь, Вы писали:

В>Здравствуйте, мыщъх, Вы писали:

М>>Здравствуйте, monax, Вы писали:

M>>>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

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

В>На самом деле если говорим именно про иерархию (а не про полиморфизм

, то надо смотреть для чего мы эту иерархию строим.
В>Иерархию надо строить от в первую очередь от процессов, а не от данных.
Хорошая мысль. Только почему именно процессы? Размышляя на эту тему я пришел к выводу что иерархии нет вообще в чистом виде. Кроме частного случая физического нахождения одного объекта в другом. Да и то его можно оспорить изменив систему координат. Иерархию объектов мы строим исходя из своего отношения к этим объектам. Отсюда следует что их (иерархий) может быть несколько. Это касается и каталога файлов и баз данных. Нет в принципе иерархических баз данных. И разумно строить несколько иерархий (или каталогов) на одно множество объектов. Объекты одного класса названы реляционной базой.. Ну что ж. Это частный случай. Потому я предлагал сделать несколько каталогов на винте. Т.е. одни и теже файлы можно собрать с каталогом своего отношения например к фильмам
1 первый каталог (любимые фильмы, фильмы для бабушкии т.д..).
2. Второй каталог по авторам
2. По жанрам.
и.т.д..
Форматирование в NTFS это позволяет делать.

В заключение скажу что название папок (уровней иерархий) не что иное как значение свойства либо самих объектов (например по цвету объекта), либо значение свойства которое приобретает объект будучи объединенный в множество. Например, значение свойства "любимый фильм" у объекта как такового нет. Но в группе объектов это свойство появляется.

Здравствуйте, Ведмедь, Вы писали:

М>>кстати, если реализовать круг как многоугольник, то достаточно одного класса "многоугольник" и никакой иерархии вообще не нужно.
В>Повторюсь — надо смотреть какие задачи будут стоят перед иерархией (структурой классов). Я вообще последнее время наследованию реализации предпочитаю агрегацию

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

Здравствуйте, monax, Вы писали:

M>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?
А иерархии нет там где ты ее не хочешь.. И есть там, где ты ее видишь

Здравствуйте, batu, Вы писали:
B>В заключение скажу что название папок (уровней иерархий) не что иное как значение свойства либо самих объектов (например по цвету объекта), либо значение свойства которое приобретает объект будучи объединенный в множество. Например, значение свойства "любимый фильм" у объекта как такового нет. Но в группе объектов это свойство появляется.
Ну это вообще спорно, про свойство группы. У группы вообще нет свойств, они пу сути обобщение на будевые индикаторы, удовлетворяет ли объект условию вхождения в группу Y.
А иерархия как таковая существует как свойство принадлежности, и как уровень вложенности и как свойство "путь в иерархии"....

Здравствуйте, igna, Вы писали:

I>Здравствуйте, monax, Вы писали:

M>>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом.

I>Так прямо все же наверное не говорится, или я не увидел? Sinclair назвал абсурдом иерархию классов геометрических фигур

Может быть пора отлелить мух от котлет, и данные о фигурах от логики их рисования?
В принципе, базовый класс "Фигура" может быть заменён интерфейсом IDrawable?
А рисованием будет заниматься

interface IDrawingStrategy<T> where T:class, IDrawable
{
    void Draw(T figure, IRenderer context);
}

В таком случае у нас может быть PrinteringRenderer, ScreenRenderer, да и FileWriter может реализовать IRenderer...

Проблема не в самом примере с фиграми, а том, что тогда ещё не было придумано отделять логику и данные от преставления. Вот скажем, чтобы круг нельзя было проткнуть треугоьником, а от прямоугольника всё отскакивало — это уже к фигурам имеет весьма отдалёное представление...

Здравствуйте, batu, Вы писали:

B>Здравствуйте, Ведмедь, Вы писали:

B> Отсюда следует что их (иерархий) может быть несколько.
наследовать можно больше чем от одного класса. замечательный способ сломать мозги.

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

таким образом -- местами со списком и массивом можно работать унифицированно и единообразно (например, вывод всех элементов). местами -- реализовывать функцию вставки в массив так же глупо как индексировать элементы списка.

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

Здравствуйте, 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>А иерархия как таковая существует как свойство принадлежности, и как уровень вложенности и как свойство "путь в иерархии"....
Вы не совсем внимательно прочитали. Я сказал что это не свойство группы, а значение нового свойства объекта возникающего при наличии этого объекта в группе определяя наше отношение к этому объекту в группе. Ну, нет у самого объекта "фильм" такого свойства "быть любимым". Оно появляется как наше отношение к фильму в группе объектов. Однако это может быть и значение существующего свойства объекта. Например, свойства цвет. Тогда мы разделим папки по значению этого свойства. Но всю иерархию мы вольны конструировать как нам вздумается.. Т.е. сначала по цветам обуви, потом по моделям, а потом по размерам. А можем и наоборот. Ни один из этих методов иерархии нельзя назвать более предпочтительным абсолютно. Они равноправны, если не применять сторонних критериев.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, batu, Вы писали:

B>>Здравствуйте, Ведмедь, Вы писали:

B>> Отсюда следует что их (иерархий) может быть несколько.
М>наследовать можно больше чем от одного класса. замечательный способ сломать мозги.

М>давайте вот такой пример. рассмотрим базовые структуры данных -- списки и массивы. очевидно, что у обоих есть что-то общее (легко реализовать итератор), а есть и принципиальные различия -- у масива очень дешево брать индекс, а в список дешево вставлять элементы в произвольное место. это сильно влияет на применимость тех или иных алгоритмов сортировки.

М>таким образом -- местами со списком и массивом можно работать унифицированно и единообразно (например, вывод всех элементов). местами -- реализовывать функцию вставки в массив так же глупо как индексировать элементы списка.

М>вот вам и полиморфизм... с другой стороны, очень удобно, когда функция может принимать в качестве аргумента и массив, и список, и словарь, и даже дерево. так что полиморфизм все-таки рулит (хоть и без руля).
Я не буду спорить с примером, котрый вы привели. Я бы отметил тут принципиальную разницу. Наследование классов и иерархия объектов это разные вещи. Ну, как событие может происходить только с объектом, и никак с классом. Итак, о чем мы говорим о наследовании или о иерархии объектов? Хотя и в иерархии объектов и в наследовании классов соглашусь с вами. Родитель должен быть один.

Здравствуйте, мыщъх, Вы писали:

Еще раз, извиняюсь. Я там ранее сказал что классы не могут иметь события, а события могут иметь только объекты. Так вот это справедливо для ООП. В моей концептной(или субъектной) парадигме классы наследуются от концептов и тоже могут иметь события.

М>первая модель, очевидно, проще. вторая модель испытывает большие проблемы с тем, что оставить в базовом класс, а что вынести в производные. скажем, Move для всех фигур реализуется одинаково, а вот вычисление площади у каждой фигуры свое. в первой модели все методы в одном классе и через switch легко группировать родственные фигуры в местах их родства. скажем, если у нас есть функция для вычисления площади N-угольника, то она будет работать для всех фигур, кроме круга. во второй модели в этом смысле жопа полная.

читая вот такие твои высказывания, меня постоянно посещает идея сделать и послать тебе crack_me, для взлома которого требовалось бы понимание теории типов и ФП

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

Здравствуйте, monax, Вы писали:

M>У меня этот вопрос возник из-за того, что по работе часто приходится общаться с плюсами. Так то я пишу на питоне и мне никакие иерархии в пень не тарахтели, потому что ежели оно крякает, то это утка. А вот когда лезу в плюсы, то хочется понимать, какие идеи в плюсах лучше.

M>И собственно я ничего плохого в shape не вижу, если этот шейп будет определять общий интерфейс для геометрических фигур.

Прочтите вот это для начала http://okmij.org/ftp/Computation/Subtyping/

Конкретно по С++, вот это http://stlab.adobe.com/wiki/index.php/Image:Regular_object_presentation.pdf
Только там весьма хардкорный С++, не для новичков.

Здравствуйте, batu, Вы писали:

B>Здравствуйте, мыщъх, Вы писали:

М>>Здравствуйте, batu, Вы писали:

М>>таким образом -- местами со списком и массивом можно работать унифицированно и единообразно (например, вывод всех элементов). местами -- реализовывать функцию вставки в массив так же глупо как индексировать элементы списка.
B>Кстати, в Вашем примере списки и стеки легко (и правильно) наследуются от массива.
и у наследованного списка сохранится родительский метод взятия элемента по индексу? это же революция в науке, блин. а если у родителя нет взятия элемента по индексу -- как мне список на базе массива реализовать?

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, batu, Вы писали:

B>>Здравствуйте, Ведмедь, Вы писали:

B>> Отсюда следует что их (иерархий) может быть несколько.
М>наследовать можно больше чем от одного класса. замечательный способ сломать мозги.
Да ладно. В жизни все объекты являются наследниками нескольких классов сразу, и ничего, люди как-то справляются, мозги не пухнут.

М>давайте вот такой пример. рассмотрим базовые структуры данных -- списки и массивы. очевидно, что у обоих есть что-то общее (легко реализовать итератор), а есть и принципиальные различия -- у масива очень дешево брать индекс, а в список дешево вставлять элементы в произвольное место. это сильно влияет на применимость тех или иных алгоритмов сортировки.

Ну вот для этого в STL и есть иерархия итераторов, но нету иерархии контейнеров.
(А в бусте еще более развернутую иерархию предложили: http://www.boost.org/libs/iterator/doc/new-iter-concepts.html)

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Ведмедь, Вы писали:

В>>Здравствуйте, monax, Вы писали:

В>>А для чего тебе иерархия? Для каких процессов? А то не понятно, важно, ли что квадрат частным случаем прямоугольника или важнее что он правильный многоугольник.
М>извините за глупость, но чем квадрат от прямоугольника отличается? геометрически тем, что квадрат задается меньшим кол-вом исходных данных. но вряд ли кто будет реализовывать изощренные способы задания квадрата и, скорее всего, функция потребует координат всех вершин. и в этом смысле квадрат все равно что треугольник.

Какая функция?

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, batu, Вы писали:

B>>Здравствуйте, мыщъх, Вы писали:

М>>>Здравствуйте, batu, Вы писали:

М>>>таким образом -- местами со списком и массивом можно работать унифицированно и единообразно (например, вывод всех элементов). местами -- реализовывать функцию вставки в массив так же глупо как индексировать элементы списка.
B>>Кстати, в Вашем примере списки и стеки легко (и правильно) наследуются от массива.
М>и у наследованного списка сохранится родительский метод взятия элемента по индексу? это же революция в науке, блин. а если у родителя нет взятия элемента по индексу -- как мне список на базе массива реализовать?
Зачем же так в лоб? Чисто с философской точки зрения достаточно того что метод взятия элемента есть и там и там. С точки зрения реализации наследования в списке пишется свой метод. С технической точки зрения иначе и быть не может. Ведь адрес ячейки памяти можно считать индексом массива. Что б мы не конструировали наследуется от массива.

Здравствуйте, jazzer, Вы писали:

B>>> Отсюда следует что их (иерархий) может быть несколько.
М>>наследовать можно больше чем от одного класса. замечательный способ сломать мозги.
J>Да ладно. В жизни все объекты являются наследниками нескольких классов сразу, и ничего, люди как-то справляются, мозги не пухнут.

Это как? Человек является наследником "желудок", наследником "рот"? Или обладает ими?

Здравствуйте, Ведмедь, Вы писали:

В>Здравствуйте, jazzer, Вы писали:

B>>>> Отсюда следует что их (иерархий) может быть несколько.
М>>>наследовать можно больше чем от одного класса. замечательный способ сломать мозги.
J>>Да ладно. В жизни все объекты являются наследниками нескольких классов сразу, и ничего, люди как-то справляются, мозги не пухнут.

В>Это как? Человек является наследником "желудок", наследником "рот"? Или обладает ими?

Это к чему было?

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, Ведмедь, Вы писали:

В>>Здравствуйте, jazzer, Вы писали:

B>>>>> Отсюда следует что их (иерархий) может быть несколько.
М>>>>наследовать можно больше чем от одного класса. замечательный способ сломать мозги.
J>>>Да ладно. В жизни все объекты являются наследниками нескольких классов сразу, и ничего, люди как-то справляются, мозги не пухнут.

В>>Это как? Человек является наследником "желудок", наследником "рот"? Или обладает ими?

J>Это к чему было?

Это к

В жизни все объекты являются наследниками нескольких классов сразу

В жизни наследование (иерархия классов) почти не встречается. Или наследником каких классов является человек?

Здравствуйте, Ведмедь, Вы писали:

B>>>>>> Отсюда следует что их (иерархий) может быть несколько.
М>>>>>наследовать можно больше чем от одного класса. замечательный способ сломать мозги.
J>>>>Да ладно. В жизни все объекты являются наследниками нескольких классов сразу, и ничего, люди как-то справляются, мозги не пухнут.

В>>>Это как? Человек является наследником "желудок", наследником "рот"? Или обладает ими?

J>>Это к чему было?

В>Это к
В>

В>В жизни все объекты являются наследниками нескольких классов сразу

И каким образом из этого утверждения следует твоя бредовая иерархия с желудком?

В>В жизни наследование (иерархия классов) почти не встречается. Или наследником каких классов является человек?
Сплошь и рядом. Я, например, наследник следующих классов: мужчина, человек (примат, млекопитающее и далее по иерархии), русский, гражданин (России), налоговый резидент (Японии), собственник, муж, отец, сын, дядя, внук, брат, сотрудник фирмы, начальник, подчиненный, военнообязанный, образованный(среднее, высшее), грамотный (рус/англ/яп), музыкант (гитара, ф-но), друг, враг, пользователь RSDN...

Здравствуйте, monax, Вы писали:

M>(из чего я могу заключить, что Sinclair не одобряет наследоване именно circle от shape)

Не знаю, возможно Sinclair подумал, что Shape у Страуструпа конкретный. Хотя конечно если и абстрактный, то такое наследование спорно.

M>И собственно я ничего плохого в shape не вижу, если этот шейп будет определять общий интерфейс для геометрических фигур.

Если бы у Страуструпа был интерфейс. У него абстрактный класс. Причем в первом же примере применения ООП в его The C++ Programming Language.

Здравствуйте, igna, Вы писали:

M>>И собственно я ничего плохого в shape не вижу, если этот шейп будет определять общий интерфейс для геометрических фигур.

I>Если бы у Страуструпа был интерфейс. У него абстрактный класс. Причем в первом же примере применения ООП в его The C++ Programming Language.

Я даже не поленился и посмотрел в книге код. У него там класс Shape, у которого только набор чисто виртуальных функций, но нет никаких данных. Что это как не интерфейс?

У меня так:

2.6.2 Class Hierarchies
. . .

class Shape {
    Point center;
    Color col;
    // ...
public:
    Point where() { return center; }
    void move(Point to) { center = to; /* ... */ draw(); }

    virtual void draw() = 0;
    virtual void rotate(int angle) = 0;
};

Здравствуйте, jazzer, Вы писали:

В>>Это к
В>>

В>>В жизни все объекты являются наследниками нескольких классов сразу

J>И каким образом из этого утверждения следует твоя бредовая иерархия с желудком?

В>>В жизни наследование (иерархия классов) почти не встречается. Или наследником каких классов является человек?
J>Сплошь и рядом. Я, например, наследник следующих классов: мужчина, человек (примат, млекопитающее и далее по иерархии), русский, гражданин (России), налоговый резидент (Японии), собственник, муж, отец, сын, дядя, внук, брат, сотрудник фирмы, начальник, подчиненный, военнообязанный, образованный(среднее, высшее), грамотный (рус/англ/яп), музыкант (гитара, ф-но), друг, враг, пользователь RSDN...

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

Здравствуйте, batu, Вы писали:

B>Зачем же так в лоб? Чисто с философской точки зрения достаточно того что метод взятия элемента есть и там и там. С точки зрения реализации наследования в списке пишется свой метод. С технической точки зрения иначе и быть не может.

Во-первых, с технической точки зрения не так давно кто-то здесь (или в "архитектуре") не помню на какую тему очень здраво говорил, что если нет родного эффективного метода count(), то и нефиг уродски-неэффективно его эмулировать в обёртке. К твоему методу взятия по индексу (который в случае списков будет именно что уродски-неэффективным) это тоже относится.

Во-вторых, учитывая полностью различные внутренние представления данных массивов и списков, тебе придётся замещать реализацию такого количества методов, что не проще ли вообще здесь от наследования одного от другого отказаться? А сделать у них просто общий интерфейс. В коллекциях в scala, впрочем, у них есть общий базовый trait — rich interface с огромным количеством реализованных высокоуровневых методов, опирающихся на абстрактные implementation-specific методы-итераторы, но эти высокоуровневые методы в подклассах как раз-таки и не переопределяются. Так что замещения реализации там, опять же, нет вообще.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, batu, Вы писали:

B>>Зачем же так в лоб? Чисто с философской точки зрения достаточно того что метод взятия элемента есть и там и там. С точки зрения реализации наследования в списке пишется свой метод. С технической точки зрения иначе и быть не может.

D>Во-первых, с технической точки зрения не так давно кто-то здесь (или в "архитектуре") не помню на какую тему очень здраво говорил, что если нет родного эффективного метода count(), то и нефиг уродски-неэффективно его эмулировать в обёртке. К твоему методу взятия по индексу (который в случае списков будет именно что уродски-неэффективным) это тоже относится.

D>Во-вторых, учитывая полностью различные внутренние представления данных массивов и списков, тебе придётся замещать реализацию такого количества методов, что не проще ли вообще здесь от наследования одного от другого отказаться? А сделать у них просто общий интерфейс. В коллекциях в scala, впрочем, у них есть общий базовый trait — rich interface с огромным количеством реализованных высокоуровневых методов, опирающихся на абстрактные implementation-specific методы-итераторы, но эти высокоуровневые методы в подклассах как раз-таки и не переопределяются. Так что замещения реализации там, опять же, нет вообще.
Как-то не вижу особых проблем. Класс массивов реализуются обычно в языке. Там проблем нет. Наследовать от него перегружаемый метод доступа для списка или стека не намного затратнее. Тем более это просто слова. И списки и стеки тоже обычно реализуются в языке. Наследуемый он или нет какая разница. Я иногда создаю стеки та именно из массивов. И не заморачиваюсь.

Здравствуйте, monax, Вы писали:

M>В начале было слово, и слово это было Что-то нетак с ООП, потом было второе слово — Так все-таки, что же не так с ООП?. Так вот, во втором слове говорится, что примеры иерархии для геометрических фигур Shape->Circle и Shape->Rectangle — это глупость и некомильфо в целом. Если так, то как же правильно это делать?

конечно все сильно зависит от задачи и требований
но имхо в данном случае наследование не имеет смысла.
лучше и правильнее использовать делегирование.
а наследование лучше делать согласно Liskov Substitution Principle.
то есть в очень редких случаях когда это действительно необходимо.

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

с этой стороны все хорошо

М>а вот решить задачу с использованием классов -- это не мое. у меня мышление на процедурно-модульном уровне.

а с этой стороны (стороны программиста) думаю полезно бы тебе написать те же фигуры на чистом си -- и скажем я бы переписал на с++ и ткнул места, которые на си хуже -- это будут касты и/или юнионы (да все это могут сделать)

разница -- кто делает касты (компилятор или программист) не очень большая, но существенная... я бы привел пример -- пИсать можно непосредственно, а можно посредством унитаза и канализации; процесс по сути тот же, но разница все же есть (хотя некоторая часть гибкости и теряется)

Здравствуйте, PSV100, Вы писали:

PSV>Напр., Implicit-выкрутасы в Scale — та ещё хрень.

Пользуясь случаем: только что гуглил на тему "scala to native compiler", а нашёл здесь следующее от одного из членов scala team (того самого, который всячески противился идее написания нормальной документации по языку, понятной людям без солидной теоретической подготовки):

It is a common myth that inheritance is related to code reuse, except perhaps that it prevents reuse to some extent under certain conditions. Inheritance is simply an implicit function (plus problems). The difference being cognitive; the arrow is pointing upward instead of rightward.

Что впрочем не отменяет того, что implicits — та ещё хрень. Проблем (и способов отстрелить себе ногу) от неё по ощущениям куда больше, чем от наследования.

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

круг должен иметь double center_x, center_y, radius;
прямоугольник должен иметь double center_x, center_y, width, height, rotation; -- sizeof больше

грубо говоря именно "sizeof больше (или тот же, но переменные имеют другое назначение)" является решающим для выделения нового класса

> скажем, Move для всех фигур реализуется одинаково

виртуальный метод Фигуры с реализацией либо вообще не виртуальный

>, а вот вычисление площади у каждой фигуры свое.

виртуальный метод

> в первой модели все методы в одном классе и через switch легко группировать родственные фигуры в местах их родства.

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

собственно ловля за руку это именно зачем ооп юзается (второй момент зачем -- это оптимизации)

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

double area(Figure* f)
{
   Polygone p = f->polygone_approximation();
   return p.area();
}

>кстати, если реализовать круг как многоугольник, то достаточно одного класса "многоугольник" и никакой иерархии вообще не нужно.

достаточно реализовать Circle::polygone_approximation()

"реализовать круг как многоугольник" плохо тем, что точность реализации может быть нужна разная для разных случаев, а Circle::polygone_approximation может принимать параметр enum WhyWeNeedApproximation (хотя, не спорю, могут быть случаи когда можно сказать "у нас только полигоны", но и тогда иерархия классов пригодится)

*тем не менее* действительно, бывают ситуации, когда ооп оказывается слишком грубым методом, и приходится (частично) прибегать к 1-й модели с целью экономии памяти или когда у нас более сложные взаимоотношения, чем иерархия -- и мне кажется, что именно эти случаи должны обсуждаться в "философии программирования", а не oop basics

если ты сможешь продвинуть свой пример до такого не-basics -- тогда будет интересно; но мне кажется, что тебе че-то надо (хотя бы быстренько) прочесть

вообще ооп это такое использование typetag-а не напрямую, а через компилятор

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

и то что я только что описал -- это первая половина квеста

вторая будет уже в поиске недостатков ооп:

у тебя есть прямой доступ к тайптегу-или-че-там-вместо-него

у меня (или кто там за ооп) нет прямого доступа

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

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

Здравствуйте, m e, Вы писали:

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

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

Здравствуйте, Ведмедь, Вы писали:

В>Здравствуйте, jazzer, Вы писали:

В>>>Это к
В>>>

В>>>В жизни все объекты являются наследниками нескольких классов сразу

J>>И каким образом из этого утверждения следует твоя бредовая иерархия с желудком?

В>>>В жизни наследование (иерархия классов) почти не встречается. Или наследником каких классов является человек?
J>>Сплошь и рядом. Я, например, наследник следующих классов: мужчина, человек (примат, млекопитающее и далее по иерархии), русский, гражданин (России), налоговый резидент (Японии), собственник, муж, отец, сын, дядя, внук, брат, сотрудник фирмы, начальник, подчиненный, военнообязанный, образованный(среднее, высшее), грамотный (рус/англ/яп), музыкант (гитара, ф-но), друг, враг, пользователь RSDN...

В>Надо начать с того, что ты перечисляешь свойства обьекта, а не класса. И получается, что это все функции, а не классы-предки. И решается это агрегацией, а не наследованием. Потому как гражданства могут лишить, можно развестись, получить новую профессию и т.д.. Как тогда убирать одно наследование, добавлять другое?

Динамически, вестимо

А агрегация тут ни при чем совершенно. Ибо я не агрегирую мужчину, я мужчиной являюсь (is-a). И не агрегирую музыканта, а им являюсь. И далее по списку.
И у каждого базового класса есть соответствующий набор методов, например, у музыканта можно узнать, на каких инструментах он играет, и позвать его на сейшен.

От:	jazzer	Skype: enerjazzer
Дата:	03.02.12 03:11
Оценка:	6 (1)

	От:	PSV100
	Дата:	03.02.12 15:23
	Оценка:	2 (2)

	От:	minorlogic
	Дата:	02.02.12 18:12
	Оценка:	+2

От:	konsoletyper	https://github.com/konsoletyper
Дата:	02.02.12 21:27
Оценка:	4 (1)

От:	мыщъх	http://nezumi-lab.org
Дата:	02.02.12 17:47
Оценка:	1 (1)

	От:	Ведмедь
	Дата:	03.02.12 07:40
	Оценка:	+1

От:	samius	http://sams-tricks.blogspot.com
Дата:	02.02.12 13:00
Оценка:

От:	dimgel	https://github.com/dimgel
Дата:	03.02.12 13:03
Оценка: