Re[10]: Зачем отказались от множественного наследования в С# - Философия программирования

Здравствуйте, Кодёнок, Вы писали:

Кё>Когда ты видишь взвод солдат, ты видишь 30 человек. Есть 30 человек. Взвода — нет.

Видишь суслика?... (с)

А почему есть 30 человек? Может это голограммы?

И вообще — что такое человек? Четкого определения ему еще не придумано.
Так что надо говорить: "Если ты видишь несколько объектов, состоящих из соединений углерода, водорода и кислорода, с небольшими примесями прочих вечеств, средней массы 80кг, но не менее 40 и не более 180, самостоятельно передвигающихся со скоростями, различающимися не более 3% в любой отдельно взятый интервал времени, и закутанных в куски аналогичных химических соединений зеленого цвета". Все прочее — только "умственные конструкции".

И это определение неполно — надо определить понятия "объект", "углерод", "кислород", "водород"...

и все остальные.

Так о чем я? А. Ты погружаешься в слишком глубокие дебри

Если я вижу взвод солдат — я вижу взвод солдат. Если мне скажут, что это туристы, я решу сам что мне видеть дальше — взвод солдат или группу туристов. Когда я смотрю кино про войну — я вижу там солдат, а не актеров, извини. А иногда — актеров, если это нужно. А иногда — клоунов.

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

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

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

Так я к чему? Человеческое сознание оперирует образами, вот так оно устроено. Оно распознает образ и работает с ним как с целым. Обвинять распознанные образы в том, что они являются "всего лишь умственными конструкциями", глупо, потому что "умственные конструкции" — это входные и выходные данные человеческого сознания. Это все равно что уточнять, что компьютер не сможет разобрать предложение, потому что в предложении — слова, а компьютер оперирует битами. Ну и что? Слова можно представить битами, можно — аналоговыми сигналами, а можно — "умственными конструкциями" в человеческом мозгу.

Да, кстати, опознать в в туристах солдат — это может быть либо:
1. ошибка. удивительно, но ошибки случаются в обработках данных с удивительной частотой.
2. допустимое обобщение. Скажем если решаешь, что будет, если попробуешь украсть у одного из них рюкзак — разница в повреждениях будет небольшая — солдаты они или туристы. Тут главное — что они — взвод!

и это вовсе не значит, что "раз это могут быть туристы, то взвода нет". Иначе ведь получится "Раз это может быть не черная кошка, а белая, облитая тушью, то значит белых кошек — нет" и тому подобное.

Вот примерно так.
Философия — дело хорошее и полезное для умственного развития, но надо удерживаться в определенных рамках

Иначе можно ведь доказать себе, что жизни — нет, и что тогда делать? Вешаться?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Интересно, а причем тут есть это в природе, или нет. Понятие искусственности/естественности метода не мало влияет на его практическую ценность. Программист он не биолог, все-таки. А кто скажет, что у наследования нет никакой практической ценности, в того кину камень. А вот у множественного наследования, имхо, весьма сомнительная практическая ценность. Чтобы ее осознать, нужно наверное пример, реализовать который с помощью множественного наследования было бы намного проще и нагляднее, чем с помощью других методов. Я такой пример привести не могу, может может кто другой?

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

R_>Наследования, специализация, это вопрос терминологии. И термин наследование, имхо, вполне адекватно и понятно отражает данную сущность.

Традиционно под наследованием понимается, что-то типа "производный класс делает все то же самое, что и базовый и плюс к тому, еще это, это и вот это". На мой взгляд, это и есть самое неправильное использование наследования. Во всяком случае, ни к чему хорошему оно никогда не приводило — получался слошной бардак и рак головы. Особенно умиляют попытки порождать производные классы от чего-то типа std::vector.

Правильное использование наследования — это замещение (override) виртуальных функций. Только оно и ничего более. От этого есть безусловная польза, но это уже становится не наследованием, а специализацией. Поэтому я и говорю, что наследование как таковое является сомнительной концепцией. Какая-то она грязноватая эта концепция, с намешанными в одну кучу разными понятиями.

B>Вот ответьте мне опытные, зачем отказались от множественного наследования ?

У меня есть одна крамольная мысль, которая может это объяснить.
Во времена "гонки жаб" (когда мелкомягкие пытались сделать "почти такую же", но свою JDK), была наработана куча кода, которая сделала своё чёрное дело (windows-native несовместимость), после чего была с почётом похоронена. Впоследствии, учтя то, что писать на MFC невозможно, а бабки нужно зарабатывать, решили из двух недостатков (недожабы и недобиблиотеки) сделать один достаток — якобы "новую" архитектуру! То бишь банально взять JVM с библиотеками и засунуть в каталог Windows, назвав всё это "многоплатформенной .NET". Разумеется, махать позорными плакатиками с Жабой было уже как-то стыдно, поэтому исходники побырому переделали и назвали жабу "си-диезом". Обратите внимание на синтаксис этих языков — да он почти неотличим! А виртуальная машина? Тот же стековый аппарат, JIT, классы...
Отсюда и ответ: да просто лень было заморачиваться! Есть уже работающая, ОДНОНАСЛЕДУЕМАЯ жаба — чего зря напрягаться?...

B>Можно ли все случаи и возможности множ.наследования в проектировании решить с одним одиноночным и n колличеством интерфейсов ?

Разумеется, НЕТ! Множественное наследование смешивает ФУНКЦИОНАЛЬНОСТЬ, а интерфейсы лишь диктуют контракт общения между классами.

Кто-то тут уже высказывал мысль, мол "МН даёт неуправляемую смесь классов". А я скажу больше — уже само наследование есть ничто иное, как смешивание в кучу своих членов и членов родителя! Это ли не есть бардак?

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

R_>Интересно, а причем тут есть это в природе, или нет. Понятие искусственности/естественности метода не мало влияет на его практическую ценность. Программист он не биолог, все-таки.

+1

вот я и говорю

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

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

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

MS>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету. Точнее есть, но она совсем из другой оперы.

В коде все должно быть прекрасно. И полиморфизм, и инкапсуляция, и наследование... (с) Асику

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

B>Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?
B>Зачем убрали возможность public/protected/private наследования даже в одиночном.
B>Можно ли все случаи и возможности множ.наследования в проектировании решить с одним одиноночным и n колличеством интерфейсов ?
B>Может где-то уже тут это обсуждалось... Интересно же знать,что думают учёные по этому поводу

Однако Вам ни кто не мешает использовать композицию классов. И вообще множественное наследование очень трудно для восприятия.

Да потому, что Хейлсберг так погрузился в паскакаль, что пропустил мимо ушей такие штуки, как policy, mixins, технику downcasting'а к шаблонным аргументам. Посуществу получилось Delphy II.

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

MS>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать.

А мне нравится

MS>Ибо нету такой штуки в природе, ну нету. Точнее есть, но она совсем из другой оперы.

А инкапсуляция с полиморфизмом есть?

... << RSDN@Home 1.2.0 alpha rev. 0>>

Полагаю чтоб упростить себе жизнь и не париться.

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

ЗЫ Уважаемые С#-ники ничего личного, среди вас я уверен есть гуру ООП и ООД, это скорее относиться к назначению языка.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Пусть у меня есть класс 3д точек с операциями сложения, векторного произведения и т.п.
АХ>И есть класс "графический объект на экране", который содержит подпись, умеет ее рисовать и т.п.

АХ>Теперь я хочу работать с точками в 3д которые также есть графические объекты на экране.
АХ>Что здесь более естественно чем двойное наследование?

Уверяю тебя, что ты не хочешь работать "с точками в 3д которые также есть графические объекты на экране". Перефразируя, можно сказать, что точке как графическому объекту на экране не нужны операции сложения, векторного произведения и т.п. Если же получается так, что они нужны, то это означает плохой дизайн и нужно срочно что-то провить в консерватории, а не порождать неестественных классов-уродцев.

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

B>....
B>class Растение
B>class Фрукт_Овощь:Растение
B>class Цветок: Растение

B>Последние два класса законченны и содержат поля.

B>Тогда
B>class Морковь:Овошь

B>И вот оно !!:
B>class Вишня:Цветок,Фрукт_Овошь
B>В роде бы всё сходиться, но реализовать такое нельзя.

B>Вишня "это есть" и цветок и фрукты_овошь.

Собственно идея что цель ООП в описании природы языком программирования — суть ошибочна. ООП — это средство, одно из многих, предназначеное для решения зачачи. А для решения задачи зачастую вовсе не требуется точное отображение природы на классы. Более того чащее всего такое отображение бесполезно. Множественое наследование — тоже лишь инструмент. Его можно использовать, а можно и обойтись без него. Разработчики СИшарпа посчитали что в этом языке такой инструмент лишний. Их право. Вообще в СИшарпе много чего нет, что моголо бы быть полезным... Плохо это или хорошо?

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

Кё>>Подумай ещё

Это трудно

В природе есть только то, что происходит прямо сейчас. Не путай реально происходящие, происходившие или будущие процессы с тем, что ты к ним домыслил.

Когда ты видишь взвод солдат, ты видишь 30 человек. Есть 30 человек. Взвода — нет. Взвод это умственная конструкция. Ты проделываешь некую операцию, группируя этих 30 человек в одно понятие "взвод". Ты руководствуешься своими представлениями о том, что такое взвод — одинаково одетые в военную форму мужчины, щагающие строем. На самом-то деле это могут быть 30 туристов со всех концов света, решившие подшутить над тобой. Когда шутка окончится, они разойдутся по своим странам. Взвода не будет. 30 человек останутся. Когда они скажут тебе что это шутка, когда убедят тебя, взвод исчезнет. Они могут продолжить шагать строем к своей гостинице, но ты уже будешь знать, что это не настоящий взвод, что это просто шутка.

Точно так же, эволюции — нет в природе. Это теория. Теория — это продукт ума. Когда-то люди не знали теории эволюции, для них эволюции не было. Когда-то они могут открыть другую теорию, которая например покажет, что то что мы знаем как эволюцию, работает не всегда и вообще является частью более сложного процесса.

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

N_C>Ну а самое простое — наследование. Достаточно посмотреть на эволюцию видов, чтобы увидеть его. Все-же произошли от простых комочкой слизи, плавающей в океане. Постепенно развивая и наследуя характеристики. Ты сам наследовал признаки от своих родителей.

Пример не очень. Наследование в C# — это расширение родительского класса. При этом пропасть ничего не может.
Наследование в природе (почему сразу за живую природу взялись

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

ИМХО, наследование хорошо соответствуюет модели человеческого мышления. Ключевое слово тут — детализация или иерархия. Например, когда человек видит предмет, его распознавание начинается с выделения контура, затем больших деталей, а затем более мелких.

Множественное наследование вызывает проблемы при реализации и использовании, к тому же mix-in его вполне успешно моделирует. Поэтому от множественного наследования и отказались.

B>Вишня "это есть" и цветок и фрукты_овошь.

Не совсем так. Что означает фраза "вишня есть цветок"? Означает ли, что вишня внутренне устроена, как цветок? Нет! Это означает, что вишня выгядит для внешнего мира, как цветок. При этом устройство может быть каким угодно. Фраза "вишня выглядит, как цветок для внешнего мира" означает, что с вишней внешний мир нужно делать все, что и с цветком, то есть:
1) Любоваться красотой
2) Нюхать
3) Опылять
4) Погадать на "любит-не-любит"

Выходит, чтобы ЛЮБОЙ объект выглядел для внешнего мира, как цветок, достаточно, чтобы с этим объектом можно было делать:

1) Любоваться красотой
2) Нюхать
3) Опылять
4) Погадать на "любит-не-любит"

То есть имеем набор операций, при наличии которых любой объект становится цветком. Этот набор называют интерфейс. Класс в шарпе может поддерживать какое угодно количество интерфейсов.

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

_>>Однако Вам ни кто не мешает использовать композицию классов. И вообще множественное наследование очень трудно для восприятия.

V>Чем труднее МН интерфейсов?

Спецэффектами.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

V>Тут как-то уже обсуждали, что было бы неплохо ввести в дотнет такую сущность как контракт в чистом виде.

Она там уже есть.

V> А пока что интерфейс в дотнет — это навроде чисто-виртуального базового класса из С++ с виртуальным наследованием, со всеми присущими ограничениями.

Нет, это ООП контракт в чистом виде. Собственно, ради этого его и придумали. А то, что в С++ вместо контракта как первоклассной сущности используются абстрактные классы, так это проблема С++.

V> И называние всего этого дела "реализацией интерфейсов" вместо "наследования" — это скорее вопрос идеологического плана...

А в этом топике вобще то и обсуждается вопрос идеологического плана.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

Не стоит тогда аппелировать к природе, это слишком общё — думаю и множественному наследованию можно найти аналогию.

Здравствуйте, Кодёнок, Вы писали:

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

R_>>Интересно, а причем тут есть это в природе, или нет. Понятие искусственности/естественности метода не мало влияет на его практическую ценность. Программист он не биолог, все-таки.
Кё>вот я и говорю
Кё>во-первых, программирование, как и математика, это чисто абстрактный придуманный мир, где мы создаем такие понятия какие хотим, и отсутствие аналогов в природе никак не может быть аргументом к целесообразности использования того или иного понятия в мире абстракций.

Кё>во-вторых, проводить аналогии с реальным миром значить ограничить сам себя, потому что в реальном мире "наследование" может иметь такие последствия, которые невозможны в вашем языке программирования, и наоборот, ваша реализация наследования в ЯП может давать такие эффекты, которых в реальном мире нет.

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

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

MS>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету.

Ну как же нету? Вот умирает дедушка и оставляет в наследство домик в деревне или там престол.

Здравствуйте, Кодёнок, Вы писали:

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

Кё>Ты плохо понимаешь что сам делаешь.
Смелое заявление

Кё> Программист работает не с реальным миром, а с его упрощенной моделью. Единственная неупрощенная модель мира — это сам мир.
Кё>Термины "модель", "математическая модель" тебе знакомы? Объекты модели могут сколь угодно точно отражать моделируемые сущности и отношения, но они не равняются им. И рано или поздно проявят неожиданные свойства в том или ином аспекте.
Тут не поспоришь, но это как раз аргумент в пользу "природного" программирования

Al_>>В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.
Кё>Не путай объекты со своим представлением о них. Они лишь могут оперировать одними и теми же терминами, похожим опытом в отношении одного и того же объекта.
Техническое задание приходит через призму восприятия программиста. А программист — такой же человек, он также эволюционировал на протяжении 2х млн. лет, жил одной среде. Мотыги, палки и прочий инструмент — ОНИ определяли его понимание этого мира.
Математика, кстати, тоже появилась не просто так — у человека возникла наобходимость ОЦЕНИВАТЬ те или иные ОБЪЕКТЫ, иметь возможность сравнивать их объективно.
А не так просто: вот я придумаю интеграл... пусть он делает то, то и то. НЕТ. У него есть ФИЗИЧЕСКИЙ СМЫСЛ (ты с этим термином знаком?). Любую единицу измерения наделяют ЭТИМ смыслом.
На основании задания программист строит СВОИ объекты — и не важно, что они отличаются от реальных — важно, чтобы они не отличались от того КАК их видит программист.
Так почему бы программисту не наделить физическим смыслом СВОИ объекты?

А как ты можешь их видеть, если вся твоя история прошла в этом мире, мире физики, мире природы?! ты по другому просто не можешь. У тебя нет такого опыта и быть не может.

Не понимаю зачем этому противиться?!

Здравствуйте, Кодёнок, Вы писали:

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

Al_>>А как ты можешь их видеть, если вся твоя история прошла в этом мире, мире физики, мире природы?! ты по другому просто не можешь.

Кё>Вот например, в природе есть слон. В программе мы можем смоделировать слона. Пользователю программы может потребоваться список слонов, у которых уши более чем на 2% меньше среднего среди слонов вообще. Для реализации тебе потребуется объект — массив слонов. Что такое массив слонов? В мире нет такого объекта. А если бы был, то он обтягивал бы почти весь земной шар, т.к. слоны с отклонениями есть на разных континентах.

Al_>>У тебя нет такого опыта и быть не может.

Кё>Какой физический смысл у массива любых объектов? Откуда такой странный опыт — массив, как людям удалось такое придумать?
Да коробок спичек, например. НАБОР любых условно-ОДНОРОДНЫХ объектов. Вполне реальный объект.

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

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

Системы с объемом исходного кода порядка десятков тысяч строк будут более понятны для восприятия сторонним программистам, если большая часть архитектуры размещена в осмысленных объектах. Или представь аналогичную систему с твоими вымышленными объектами

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

Да и полную картину увидеть проще.

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

B>Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?

Мнение сотрудников из Майкрософт
http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85562.aspx
http://blogs.msdn.com/nickmalik/archive/2004/12/31/344966.aspx

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

MS>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету. Точнее есть, но она совсем из другой оперы.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

dshe wrote:
>> > L> Ибо это практически всегда ошибка дизайна.
>> > Да это ж гордость дизайна С++! Даймонд вперед всего применили именно в
>> > stdlib.
> C>А где там оно используется?
> имеется ввиду наверное <iostream>. класс iostream наследуется от istream
> и от ostream, которые, в свою очередь, имеют общего предка ios.
Точно. Ну если ради запрета diamond придется передизайнить библиотеку
потоков — то это еще один большой плюс

Потоки в С++ — это самая
неудачная и запутанная часть стандартной библиотеки.

Posted via RSDN NNTP Server 2.0

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

Al_>А как ты можешь их видеть, если вся твоя история прошла в этом мире, мире физики, мире природы?! ты по другому просто не можешь.

Вот например, в природе есть слон. В программе мы можем смоделировать слона. Пользователю программы может потребоваться список слонов, у которых уши более чем на 2% меньше среднего среди слонов вообще. Для реализации тебе потребуется объект — массив слонов. Что такое массив слонов? В мире нет такого объекта. А если бы был, то он обтягивал бы почти весь земной шар, т.к. слоны с отклонениями есть на разных континентах.

Al_>У тебя нет такого опыта и быть не может.

Какой физический смысл у массива любых объектов? Откуда такой странный опыт — массив, как людям удалось такое придумать?

Какой физический смысл у объектов-оберток? Что моделирует объект, который существует лишь из-за технического ограничения — часть кода должна была быть написана на другом ЯП? Ему даже название трудно придумать, он ничего не делает, он ничего не представляет, просто в вашей реализации ЯП это оказался единственный способ. Так вот веришь-нет, из таких объектов, которые изначально ничего из природы не моделируют, можно строить целые системы, которые будут делать то, что тебе нужно.

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

Кё>>Какой физический смысл у массива любых объектов? Откуда такой странный опыт — массив, как людям удалось такое придумать?
Al_>Да коробок спичек, например. НАБОР любых условно-ОДНОРОДНЫХ объектов. Вполне реальный объект.

Коробок спичек, это просто удобный частный случай. Расскажи лучше про смысл массива слонов, который необходим чтобы listview мог отобразить произвольную выборку индивидов. Или про массив всех спичек некоторого завода за 2005-й год, у которых отсутствует головка (брак). Где у них соответствующий реальный объект?

Кё>>Какой физический смысл у объектов-оберток? Что моделирует объект, который существует лишь из-за технического ограничения — часть кода должна была Al_>Не хотел бы я работать с такой системой. В ней черт ногу сломит.

А тебя не спрашивают, что бы ты хотел. Когда в системе есть библиотека А, которая использует std::string, и есть библиотека Б, которая использует MyFooString, тебе нужно написать пару "бессмысленных" функций и оберток чтобы их данные свободно передавались между объектами библиотек. Эти пара непонятных функций нужны чтобы остальные 90% системы сделать читабельными, прозрачными и понятными.

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

http://www.rsdn.ru/search/?q=%EC%ED%EE%E6%E5%F1%F2%E2%E5%ED%ED%EE%E5+%ED%E0%F1%EB%E5%E4%EE%E2%E0%ED%E8%E5&mode=rank&group=1001

MS>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету. Точнее есть, но она совсем из другой оперы.
Как это нету? А симбиоз организмов? Его можно рассматривать как некий механизм наследования.

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

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

B>>Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?
B>>Зачем убрали возможность public/protected/private наследования даже в одиночном.
B>>Можно ли все случаи и возможности множ.наследования в проектировании решить с одним одиноночным и n колличеством интерфейсов ?
B>>Может где-то уже тут это обсуждалось... Интересно же знать,что думают учёные по этому поводу

_>Однако Вам ни кто не мешает использовать композицию классов. И вообще множественное наследование очень трудно для восприятия.

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

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

Кё>Инкапсуляция, полиморфизм, наследование — всё это чисто умственные операции, в природе их нет.
Инкапсуляция — это любое живое существо — которое иикапсулирует обработку сигналов (например чтобы заставить собаку сидеть не надо подходить к ней и расставлять ей ноги и т.п. — достаточно сказать — "Сидеть"). Желудок. Там живут кучи бактерий, которых не видно, но которые тем не менее перерабатывают пищу.
Наследование — это пример всех иерархии видов животных, которые выстроили биологи.
С полиморфизмом сложнее. Но и тут можно найти пример. Одно и то-же желание есть заставит по разному действовать разных животных.

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

Кё>>Инкапсуляция, полиморфизм, наследование — всё это чисто умственные операции, в природе их нет.
N_C>Инкапсуляция — это любое живое существо — которое иикапсулирует обработку сигналов (например чтобы заставить собаку сидеть не надо подходить к ней и расставлять ей ноги и т.п. — достаточно сказать — "Сидеть"). Желудок. Там живут кучи бактерий, которых не видно, но которые тем не менее перерабатывают пищу.
N_C>Наследование — это пример всех иерархии видов животных, которые выстроили биологи.
N_C>С полиморфизмом сложнее. Но и тут можно найти пример. Одно и то-же желание есть заставит по разному действовать разных животных.

Подумай ещё

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

Но в природе этого НЕТ

Кё>>>Подумай ещё
Кё>Это трудно
Трудно понять мои мысли?

Кё>В природе есть только то, что происходит прямо сейчас. Не путай реально происходящие, происходившие или будущие процессы с тем, что ты к ним домыслил.
Мне не хочется с тобой спорить... Просто потому, что я не принадлежу к тем философам, которые говорят: "Я мыслю, значит
существую".

Кё>Точно так же, эволюции — нет в природе. Это теория. Теория — это продукт ума. Когда-то люди не знали теории эволюции...
Вообще-то, развивая твою мысль: "Все программирование это не более чем теория и продукт ума".

F>>Философия — дело хорошее и полезное для умственного развития, но надо удерживаться в определенных рамках Иначе можно ведь доказать себе, что жизни — нет, и что тогда делать? Вешаться?
Кё>Это так заявляют те, кто упершись в первый неразрешимый вопрос, в первый парадокс — тут же сдался

Знаешь, а может просто нет времени с тобой препираться? Смысла нет. С софистом бесполезно спорить, он все-равно докажет, что солнце зеленое, а земля плоская.

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

MF>Делать их синглтонами — все равно, что сказать, что кроме Васи и Пети больше Человеков не существует.
Нет, нет, делать их синглтонами — это значит что других таких Васи и Пети больше не существует!
Ведь ничто не запрещает сделать синглтоном Машу и Колю...

Never underestimate those behind you...

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

V>>В нединамических языках полиморфизм только через наследование и бывает.

AVK>Для полиморфизма нужно наследование только контракта. Наследовать для этого реализацию совсем не обязательно.

Тут как-то уже обсуждали, что было бы неплохо ввести в дотнет такую сущность как контракт в чистом виде. А пока что интерфейс в дотнет — это навроде чисто-виртуального базового класса из С++ с виртуальным наследованием, со всеми присущими ограничениями. И называние всего этого дела "реализацией интерфейсов" вместо "наследования" — это скорее вопрос идеологического плана...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Мое ИМХО такое: отказались по достаточно простой причине — большинство программистов не умеют правильно пользоваться наследованием. Пренебрегая наследованием интерфейсов (где это можно было сделать), злоупотребляют наследованием реализации (где можно было вообще обойтись без наследования), при этом искажая логику поведения унаследованных классов. А множественное наследование реализаций может увеличть неразбериху на порядок

Здравствуйте, Андрей Хропов, Вы писали:

АХ>>>Пусть у меня есть класс 3д точек с операциями сложения, векторного произведения и т.п.
АХ>>>И есть класс "графический объект на экране", который содержит подпись, умеет ее рисовать и т.п.

АХ>Вот у меня есть куча точек которые есть графические объекты (скажем это частицы какие-нибудь в particle system), хочу я их все сдвинуть на вектор. Естественно для этого применить операцию которая есть в классе вектор.

Подразумевается, что кроме точек есть и другие типы объектов, так? То есть, кружочки, шарики, кубики. И у всех их должна быть операция "сдвинуть на вектор" (то есть, виртуальный метод такой). Иными словами, операция "сдвинуть на вектор" является первичной по отношению к классу "графический объект на экране" и весьма вторичной по отношению к классу "точка 3d". класс "точка 3d" может вообще не иметь этой операции,а вот "точка_3d_как_графический_объект_на_экране" — обязан по контракту. Если же у нас только точки умеют двигаться, а прочие объекты не умеют, то это надо лечить.

АХ>А ты что предложишь?

Инкапсулировать "точка_3d" в "точка_3d_как_графический_объект_на_экране" и выставлять (expose) только те методы, которые реально необходимы. На поверку как правило оказывается, что практически ничего из фуцнкциональности "точка_3d" не требуется. А если что-то требуется, то немного не так, а через какой-то адаптор. Иными словами, ты не хочешь работать с точками в 3д которые также есть графические объекты на экране.

vdimas wrote:
> ИМХО, перезагрузку сигнатур ф-ий тоже стоило бы отнести к определенному
> виду полиморфности, если считать за таковую специализацию шаблонов. Как
> тебе?
Ну как бы оно тоже считается "статическим полиморфизмом".

Posted via RSDN NNTP Server 2.0

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

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

R_>>Наследования, специализация, это вопрос терминологии. И термин наследование, имхо, вполне адекватно и понятно отражает данную сущность.

MS>Традиционно под наследованием понимается, что-то типа "производный класс делает все то же самое, что и базовый и плюс к тому, еще это, это и вот это". На мой взгляд, это и есть самое неправильное использование наследования. Во всяком случае, ни к чему хорошему оно никогда не приводило — получался слошной бардак и рак головы. Особенно умиляют попытки порождать производные классы от чего-то типа std::vector.

MS>Правильное использование наследования — это замещение (override) виртуальных функций. Только оно и ничего более. От этого есть безусловная польза, но это уже становится не наследованием, а специализацией. Поэтому я и говорю, что наследование как таковое является сомнительной концепцией. Какая-то она грязноватая эта концепция, с намешанными в одну кучу разными понятиями.

Согласен. Добавлю к сказанному от себя.

Чисто теоретически, множественное наследование действительно иногда может быть уместным. Это тот очень редкий случай, когда производный класс является полной суммой своих предков. Но проблема множественного наследования заключается в том, что предвидеть этот случай на этапе проектирования крайне трудно. В итоге, практика использования множественного наследования сводится к следующему сценарию:

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

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

3) Ввиду того, что при применении наследования, и тем более, множественного наследования у нас получается весьма железобетонная архитектура (антоним гибкой), то начинаются пляски с бубном, которые выражаются в:
-- жутких архитектурных хаках
-- банальном copy/paste
-- нагромождении if/switch
На подобные шалости уже закрываются глаза, так как "проект надо было сдавать еще вчера". В итоге, код становится помойкой.

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

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

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

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

class ATL_NO_VTABLE CXyz:
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CXyz, &CLSID_Xyz>,
    public IDispatchImpl<IXyz, &IID_IXyz, &LIBID_ATLXyzLib, 1, 0>
{
...
};

Почему множественного наследования нет в C#? Я думаю потому, что его нет в яве и объект-паскале

Почему его нет в яве? Видимо, как здесь уже говорили, из-за трудностей со сборкой мусора и тем, что все классы должны наследоваться от Object, что и приводит к ромбовидному наследованию в ста процентах случаев...

Вообще, я не понимаю, почему, с точки зрения многих противников МН, одиночное наследование — допустимо? По мне, так это просто вырожденный случай, которые несет все его недостатки и достоинства. Если быть последовательным, то надо либо вообще не использовать наследование реализации, либо признать, что применяемое с умом множественное наследование ничуть не хуже одиночного.

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

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

Офигеть.

В этом случае все элементы статически-типизированных языков претендуют на статический полиморфизм.
Например:
operator+(int, int)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

Ты плохо понимаешь что сам делаешь. Программист работает не с реальным миром, а с его упрощенной моделью. Единственная неупрощенная модель мира — это сам мир.

Термины "модель", "математическая модель" тебе знакомы? Объекты модели могут сколь угодно точно отражать моделируемые сущности и отношения, но они не равняются им. И рано или поздно проявят неожиданные свойства в том или ином аспекте.

Al_>В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.

Не путай объекты со своим представлением о них. Они лишь могут оперировать одними и теми же терминами, похожим опытом в отношении одного и того же объекта.

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

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

Кё>>>во-вторых, проводить аналогии с реальным миром значить ограничить сам себя, потому что в реальном мире "наследование" может иметь такие последствия, которые невозможны в вашем языке программирования, и наоборот, ваша реализация наследования в ЯП может давать такие эффекты, которых в реальном мире нет.

Al_>>Категорически не согласен. Программирование должно быть... или нет, не "должно быть", а должно иметь возможность быть тесно связанным с тем миром для которого реализуется программный код.
Al_>>В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.

F>см. выделенное.
F>Обычно не программируют живую природу

F>Я реализую код для автоматизации работы, скажем, операциониста в банке... И что, думаешь, он оперирует понятиями "объект" или "наследование"?
F>Нет.
Почему нет?! Ты спроси у нее. Она расскажет тебе — только другими словами. Так как это естественные понятия для человека. Здесь писали, что "наследование" — это не совсем тот термин. Я с этим согласен. Здесь будут разногласия у тебя с операционистом.
Также при желании можешь вытянуть из пользователя понятие "типа объекта" и его "экзампляра".

F>Но это не мешает удобно представить сущности с которыми он реально работает в виде объектов

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

Q>Разумеется, НЕТ! Множественное наследование смешивает ФУНКЦИОНАЛЬНОСТЬ, а интерфейсы лишь диктуют контракт общения между классами.

Функциональность можно смешать не только наследованием.

Q>Кто-то тут уже высказывал мысль, мол "МН даёт неуправляемую смесь классов". А я скажу больше — уже само наследование есть ничто иное, как смешивание в кучу своих членов и членов родителя! Это ли не есть бардак?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?
Зачем убрали возможность public/protected/private наследования даже в одиночном.
Можно ли все случаи и возможности множ.наследования в проектировании решить с одним одиноночным и n колличеством интерфейсов ?
Может где-то уже тут это обсуждалось... Интересно же знать,что думают учёные по этому поводу

02.08.06 01:22: Перенесено модератором из '.NET' — TK

ops public конечно же остался.

Ветка обещает быть многоочковой

В "философию" прям щас.

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

G>В коде все должно быть прекрасно. И полиморфизм, и инкапсуляция, и наследование... (с) Асику

Сначала следование, выбор и повторение, а потом уже вышеперечисленное

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

B>>Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?

MS>И правильно сделали. Жаль, что вообще не запретили наследование. Ибо наследование в программировании компьютеров — это самая противоестественная вещь, которую только можно придумать. Достаточно вспомнить недавний спор на РСДН о том, кто от кого должен наследоваться — квадрат от прямоугольника или наоборот(!) — Это же просто цирк с конями сферическими в вакууме!

MS>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету. Точнее есть, но она совсем из другой оперы.

Инкапсуляция, полиморфизм, наследование — всё это чисто умственные операции, в природе их нет.

Наследование — неверное название, правильное — что-то вроде конкретизаци, т.е. обратное обобщению.

Кё>Подумай ещё
Перечитай еще раз мой пост.

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

Инкапсуляция — вообще самое простое. Ты ешь пищу и перерабатываешь ее в энергию. Что скрывается за этим процессом — тебя самого не интересует.

Ну а самое простое — наследование. Достаточно посмотреть на эволюцию видов, чтобы увидеть его. Все-же произошли от простых комочкой слизи, плавающей в океане. Постепенно развивая и наследуя характеристики. Ты сам наследовал признаки от своих родителей.

Кё>Но в природе этого НЕТ

Но оно есть

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

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

N_C>С полиморфизмом сложнее. Но и тут можно найти пример. Одно и то-же желание есть заставит по разному действовать разных животных.

Полиморфизм — в биологии (от греч. polymorphos — многообразный) — способность некоторых организмов существовать в состояниях с различной внутренней структурой или в разных внешних формах.

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

Wikipedia

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Полиморфизм — в биологии (от греч. polymorphos — многообразный) — способность некоторых организмов существовать в...

Ну мы же не сравниваем как различаются определения. Мы же сравниваем то, что понимают под программным определением полиморфизма.

Здравствуйте, Кодёнок, Вы писали:

Кё>Наследование — неверное название, правильное — что-то вроде конкретизаци, т.е. обратное обобщению.

Наследование (публичное) применяется как правило для двух целей: специализации или спецификации.

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

В первом случае имеем наследование реализации и интерфейса родителя, во втором — только интерфейса родителя. В обоих случаях класс является is-a родителя, что позволяет использовать открытое наследование для реализации полиморфизма в статически типизированных языках как С#, C++, Java. Для проверки, является ли наследование отношением "is-a", можно воспользоваться принципом подстановки Барбары Лисковой

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

_>Однако Вам ни кто не мешает использовать композицию классов. И вообще множественное наследование очень трудно для восприятия.

Чем труднее МН интерфейсов?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

....
class Растение
class Фрукт_Овощь:Растение
class Цветок: Растение

Последние два класса законченны и содержат поля.

Тогда
class Морковь:Овошь

И вот оно !!:
class Вишня:Цветок,Фрукт_Овошь
В роде бы всё сходиться, но реализовать такое нельзя.

Вишня "это есть" и цветок и фрукты_овошь.

Являеться ли всё выше изложенное таковым или стоит плесать в аналогичных случаях в разных похожих примерах из разных областей от:
У кого-то,тот кто будет возможно доказывать, что это не так, вишня будет ассоциироваться с одним, а у кого-то со вторым и по теории тогда можно просто поступить так:

class Дерево
class Вишня:Дерево
{ в полях реализовать отношение "has a" для цвета и плода }

Но это смахивает на подгонку правильного подхода к тому, что позволяет язык С# ?

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

B>Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?

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

При этом с точки зрения объектной модели множественное наследование и одиночное наследование+множественные интерфейсы — соверешнно одинаковы. Множественное наследование дает плюс в том, что оно позволяет наследовать готовую реализацию от нескольких базовых классов. Но на практике необходимость в этом возникает редко, и можно ничуть не хуже реализовать то же самое при помощи делегирования и интерфейса. А разбираться в подобном дереве наследования становится гораздо легче.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

R_>Интересно, а причем тут есть это в природе, или нет. Понятие искусственности/естественности метода не мало влияет на его практическую ценность. Программист он не биолог, все-таки. А кто скажет, что у наследования нет никакой практической ценности, в того кину камень. А вот у множественного наследования, имхо, весьма сомнительная практическая ценность.

Следующим шагом будет осознание, что и у просто наследования практическая ценость весьма сомнительна. Имеется единственный случай, когда наследование оправдано — это перегрузка виртуальных функций. Но это следовало бы назвать не наследованием, а специализацией. А тот случай, когда есть класс String, не имеющий ни одной виртуальной функции, и от него образуется некий производный класс с расширенной функциональностью, то это ересь. Это в результате приводит к гораздо большим проблемам, чем дает практической ценности. Наследование применимо к интерфейсам, но это тоже не наследование, это — имплементация.

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

F>Так я к чему? Человеческое сознание оперирует образами, вот так оно устроено. Оно распознает образ и работает с ним как с целым. Обвинять распознанные образы в том, что они являются "всего лишь умственными конструкциями", глупо, потому что "умственные конструкции" — это входные и выходные данные человеческого сознания.

Давай так скажу: местный дикарь увидит тех же самых людей, но не увидит взвода, т.к. такого понятия ему не знакомо.

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

Отличай то, что ты видишь, от того, что ты додумываешь. Это нужно для того, чтобы не заявлять например, "наследования в природе не существует". Не "не существует", а "не сумел найти". А "существует" на самом деле значит — сумел так отфильтровать несущественное и выделить главное, что наследование стало очевидным.

F>Философия — дело хорошее и полезное для умственного развития, но надо удерживаться в определенных рамках Иначе можно ведь доказать себе, что жизни — нет, и что тогда делать? Вешаться?

Это так заявляют те, кто упершись в первый неразрешимый вопрос, в первый парадокс — тут же сдался

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

MS>Следующим шагом будет осознание, что и у просто наследования практическая ценость весьма сомнительна. Имеется единственный случай, когда наследование оправдано — это перегрузка виртуальных функций. Но это следовало бы назвать не наследованием, а специализацией. А тот случай, когда есть класс String, не имеющий ни одной виртуальной функции, и от него образуется некий производный класс с расширенной функциональностью, то это ересь. Это в результате приводит к гораздо большим проблемам, чем дает практической ценности. Наследование применимо к интерфейсам, но это тоже не наследование, это — имплементация.

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

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

R_>Наследования, специализация, это вопрос терминологии. И термин наследование, имхо, вполне адекватно и понятно отражает данную сущность. А вопрос где оно оправдано, а где нет, достаточно спорный. Кому не нравится, вполне может выбрать другой способ реализации, благо подавляющее большинство задач можно решить не одним, и даже не двумя методами.

Проблема чаще всего заключается в том, что то, что нравится одному разработчику, не нравится другому. Один разработчик предпочитает создавать экземпляры "Вася" и "Петя" класса "Человек", а другой создавать подклассы "Вася" и "Петя" от базового "Человек" (и делать их потом синглтонами). Это идеальный случай когда разработчик сам наступает на свои же грабли -- в этом случае он имеет возможность учиться на своих ошибках и избегать их в последствии. Чаще приходится наступать на чужие грабли. Поэтому "не нравится -- не используй" является сомнительным аргументом.

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

D>Проблема чаще всего заключается в том, что то, что нравится одному разработчику, не нравится другому. Один разработчик предпочитает создавать экземпляры "Вася" и "Петя" класса "Человек", а другой создавать подклассы "Вася" и "Петя" от базового "Человек" (и делать их потом синглтонами). Это идеальный случай когда разработчик сам наступает на свои же грабли -- в этом случае он имеет возможность учиться на своих ошибках и избегать их в последствии. Чаще приходится наступать на чужие грабли. Поэтому "не нравится -- не используй" является сомнительным аргументом.

Вася и Петя — это явно экземпляры класса Человек. Тут расхождений у нормальных разработчиков быть не может.
Делать их синглтонами — все равно, что сказать, что кроме Васи и Пети больше Человеков не существует.
Я не хотел бы сопровождать такой проект.

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

D>Проблема чаще всего заключается в том, что то, что нравится одному разработчику, не нравится другому. Один разработчик предпочитает создавать экземпляры "Вася" и "Петя" класса "Человек", а другой создавать подклассы "Вася" и "Петя" от базового "Человек" (и делать их потом синглтонами). Это идеальный случай когда разработчик сам наступает на свои же грабли -- в этом случае он имеет возможность учиться на своих ошибках и избегать их в последствии. Чаще приходится наступать на чужие грабли. Поэтому "не нравится -- не используй" является сомнительным аргументом.

При работе с чужим программным кодом, с которым ты несколько не согласен обычно возникают два варианта мыслей. Первый, «Это сколько же надо было выпить, чтобы так сделать», и второй «Я бы сделал не так, но это тоже неплохо». Я имел в виду вариант 2. Это уже вопрос квалификации разработчика. Но даже любых двух программистов с примерно одинаковой квалификацией есть свои предпочтения в способах разработки, которые иногда кардинальное различаются. Естественно, при совместной деятельности, приходится это как-то согласовывать.

S>Нет, нет, делать их синглтонами — это значит что других таких Васи и Пети больше не существует!
S>Ведь ничто не запрещает сделать синглтоном Машу и Колю...

Сначала я тоже так подумал, но вот куда девать клонирование... Если верить ученым при этом появляется особь, полностью идентичная своему "родителю"...

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

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

MF>>Делать их синглтонами — все равно, что сказать, что кроме Васи и Пети больше Человеков не существует.
S>Нет, нет, делать их синглтонами — это значит что других таких Васи и Пети больше не существует!
S>Ведь ничто не запрещает сделать синглтоном Машу и Колю...

Это похоже на обфускацию ручной работы

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

B>Вишня "это есть" и цветок и фрукты_овошь.

B>Являеться ли всё выше изложенное таковым или стоит плесать в аналогичных случаях в разных похожих примерах из разных областей от:
B>У кого-то,тот кто будет возможно доказывать, что это не так, вишня будет ассоциироваться с одним, а у кого-то со вторым и по теории тогда можно просто поступить так:

B>class Дерево
B>class Вишня:Дерево
B>{ в полях реализовать отношение "has a" для цвета и плода }

B>Но это смахивает на подгонку правильного подхода к тому, что позволяет язык С# ?

Но вишня одновременно не может одновременно цвести и давать фрукты!!! поэтому наследование реализации не корректно, что вы и доказали

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

V>В нединамических языках полиморфизм только через наследование и бывает.

Для полиморфизма нужно наследование только контракта. Наследовать для этого реализацию совсем не обязательно.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

MS>Традиционно под наследованием понимается, что-то типа "производный класс делает все то же самое, что и базовый и плюс к тому, еще это, это и вот это". На мой взгляд, это и есть самое неправильное использование наследования. Во всяком случае, ни к чему хорошему оно никогда не приводило — получался слошной бардак и рак головы. Особенно умиляют попытки порождать производные классы от чего-то типа std::vector.

MS>Правильное использование наследования — это замещение (override) виртуальных функций. Только оно и ничего более. От этого есть безусловная польза, но это уже становится не наследованием, а специализацией. Поэтому я и говорю, что наследование как таковое является сомнительной концепцией. Какая-то она грязноватая эта концепция, с намешанными в одну кучу разными понятиями.

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

1) Со множественным наследованием есть проблемы (например Diamond problem). Так как если использовать его без меры граф наследования становится запутанным и становится трудно понять что к чему. Так же могут появится и циклические ссылки, отсюда непонятки с порядком вызова конструкторов,
дополнительный геморрой с виртуальным наследованием и т. п.

2) Технические проблемы с реализацией в среде со сборкой мусора.

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

вот выдержка из S.Lippman "Inside the C++ Object model", раздел 3.4
(надеюсь меня не убьют за цитирование копирайченного материала ) :

Multiple inheritance is neither as well behaved nor as easily modeled as single inheritance. The complexity of multiple inheritance lies in the "unnatural" relationship of the derived class with its second and subsequent base class subobjects. Consider, for example, the following multiply derived class, Vertex3d:
class Point2d { 
public: 
   // ... 
protected: 
   float _x, _y; 
}; 

class Vertex { 
public: 
   // ... 
protected: 
   Vertex *next; 
}; 

class Vertex2d : 
   public Point2d, public Vertex { 
public: 
   //... 
protected: 
   float mumble; 
};
The problem of multiple inheritance primarily affects conversions between the derived and second or subsequent base class objects, either directly
extern void mumble( const Vertex& ); 
Vertex3d v; 
... 
// conversion of a Vertex3d to Vertex is ``unnatural'' 
mumble( v );
or through support for the virtual function mechanism. The problems with supporting virtual function invocation are discussed in Section 4.2.

The assignment of the address of a multiply derived object to a pointer of its leftmost (that is, first) base class is the same as that for single inheritance, since both point to the same beginning address. The cost is simply the assignment of that address (Figure 3.4 shows the multiple inheritance layout). The assignment of the address of a second or subsequent base class, however, requires that that address be modified by the addition (or subtraction in the case of a downcast) of the size of the intervening base class subobject(s). For example, with

Figure 3.4. Data Layout: Multiple Inheritance
Vertex3d v3d; 
Vertex  *pv; 
Point2d *pp; 
Point3d *p3d;
the assignment
pv = &v3d;
requires a conversion of the form
// Pseudo C++ Code 
pv = (Vertex*)(((char*)&v3d) + sizeof( Point3d ));
whereas the assignments
pp  = &v3d; 
p3d = &v3d;
both simply require a copying of the address. With
Vertex3d *p3d; 
Vertex   *pv;
the assignment
pv = p3d;
cannot simply be converted into
// Pseudo C++ Code 
pv = (Vertex*)((char*)p3d) + sizeof( Point3d );
since, if p3d were set to 0, pv would end up with the value sizeof(Point3d). So, for pointers, the internal conversion requires a conditional test:
// Pseudo C++ Code 
pv = p3d 
   ? (Vertex*)((char*)p3d) + sizeof( Point3d ) 
   : 0;
Conversion of a reference need not defend itself against a possible 0 value, since the reference cannot refer to no object.

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

Это еще без виртуального наследования, которое дополнительно усложняет ситуацию, о чем там дальше идет речь.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

MS>>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету. Точнее есть, но она совсем из другой оперы.

V>В нединамических языках полиморфизм только через наследование и бывает.
Что за глупость.
Перегрузка операторов и генерики/шаблоны тот же полиморфизм, только времени компиляции.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

B>>Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?
B>>Зачем убрали возможность public/protected/private наследования даже в одиночном.
B>>Можно ли все случаи и возможности множ.наследования в проектировании решить с одним одиноночным и n колличеством интерфейсов ?
B>>Может где-то уже тут это обсуждалось... Интересно же знать,что думают учёные по этому поводу

_>Да потому, что Хейлсберг так погрузился в паскакаль, что пропустил мимо ушей такие штуки, как policy, mixins, технику downcasting'а к шаблонным аргументам. Посуществу получилось Delphy II.
Ответил здесь.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету.

А конструкторы в природе есть? А делегаторы?

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Так же могут появится и циклические ссылки
Нет, с циклическами это я пожалуй маху дал

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

g_i>А конструкторы в природе есть? А делегаторы?

Ну что за придирки к словам? Все это в природе есть, если понимать под "природой" не цветочки-лютики, а разнообразые сущности и процессы, которые мы моделируем. Как-то, денежные операции, квантово-механические процессы, электромеханическтие устройства, и т.д.

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

MS>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>Пусть у меня есть класс 3д точек с операциями сложения, векторного произведения и т.п.
АХ>>И есть класс "графический объект на экране", который содержит подпись, умеет ее рисовать и т.п.

АХ>>Теперь я хочу работать с точками в 3д которые также есть графические объекты на экране.
АХ>>Что здесь более естественно чем двойное наследование?

MS>Уверяю тебя, что ты не хочешь работать "с точками в 3д которые также есть графические объекты на экране". Перефразируя, можно сказать, что точке как графическому объекту на экране не нужны операции сложения, векторного произведения и т.п. Если же получается так, что они нужны, то это означает плохой дизайн и нужно срочно что-то провить в консерватории, а не порождать неестественных классов-уродцев.

Почему это плохой дизайн я не вижу. Как лучше то?

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

А ты что предложишь?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Андрей Хропов wrote:
> Вот у меня есть куча точек которые есть графические объекты (скажем это
> частицы какие-нибудь в particle system), хочу я их все сдвинуть на
> вектор. Естественно для этого применить операцию которая есть в классе
> вектор.
> А ты что предложишь?
Вообще говоря, в графических системах обычно делается разделение между
объектами и их преобразованиями.

Таким образом, мы можем использовать одну модель (единственную particle)
и размножить ее просто используя разные преобразования.

Но это детали, мне самому MH нравится так как позволяет использовать
mixin'ы и ряд интересных приемов.

Posted via RSDN NNTP Server 2.0

Здравствуйте, Андрей Хропов, Вы писали:

V>>В нединамических языках полиморфизм только через наследование и бывает.
АХ>Что за глупость.
АХ>Перегрузка операторов и генерики/шаблоны тот же полиморфизм, только времени компиляции.

Этот полиморфизм скорее к кодогенерации относится, чем к обсуждаемому ООП.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>Здравствуйте, Андрей Хропов, Вы писали:

V>>>В нединамических языках полиморфизм только через наследование и бывает.
АХ>>Что за глупость.
АХ>>Перегрузка операторов и генерики/шаблоны тот же полиморфизм, только времени компиляции.

V>Этот полиморфизм скорее к кодогенерации относится, чем к обсуждаемому ООП.
Нормально.

Статической полиморфности не существует потому как это кодогенерация.

Частичная специализация для шаблонов тоже кодогенерация?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

C>Но это детали, мне самому MH нравится так как позволяет использовать
C>mixin'ы и ряд интересных приемов.

Согласен на 100%. МН это инструмент, который позволяет как плодить гибриды ежа с ужом, так и делать миксины которые ИМХО есть мегаудобный способ для того чтобы научить ежей плясать кадриль и ездить на велосипеде

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

АХ>1) Со множественным наследованием есть проблемы (например Diamond problem). Так как если использовать его без меры граф наследования становится запутанным и становится трудно понять что к чему.

Я б с лёгким сердцем просто запретил бы Diamond

По крайней мере, в С++. Ибо это практически всегда ошибка дизайна. Конечно, в Java/C# когда всё есть object, это не так-то просто.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Left2 wrote:
> Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
> Ибо это практически всегда ошибка дизайна. Конечно, в Java/C# когда всё
> есть object, это не так-то просто.
Аналогично, не помню случая когда мне Diamond понадобился бы.

Posted via RSDN NNTP Server 2.0

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

V>>>>В нединамических языках полиморфизм только через наследование и бывает.
АХ>>>Что за глупость.
АХ>>>Перегрузка операторов и генерики/шаблоны тот же полиморфизм, только времени компиляции.

V>>Этот полиморфизм скорее к кодогенерации относится, чем к обсуждаемому ООП.
GZ>Нормально.

Статической полиморфности не существует потому как это кодогенерация.

Словосочетание "статическая полиморфность" — софизм сам по себе.

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

GZ>Частичная специализация для шаблонов тоже кодогенерация?

Именно

Особенно частичная.

Или попробуй пойти от обратного и поискать здесь ОПП. Например, на шаблонных свободных ф-иях.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>Left2 wrote:
>> Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
>> Ибо это практически всегда ошибка дизайна. Конечно, в Java/C# когда всё
>> есть object, это не так-то просто.
C>Аналогично, не помню случая когда мне Diamond понадобился бы.

А он не и надобится, он сам приходит.

D>А он не и надобится, он сам приходит.

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

Как раз приведённую ситуацию я считаю ошибкой дизайна — попыткой получения ужеежей.

Ну и если Diamond будет запрещён, то и виртуального наследования никакого не будет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Left2, Вы писали:
L>Я б с лёгким сердцем просто запретил бы Diamond

По крайней мере, в С++.
Ага. И прощай <stdio>?
L> Ибо это практически всегда ошибка дизайна.
Да это ж гордость дизайна С++! Даймонд вперед всего применили именно в stdlib.

1.1.4 stable rev. 510

Sinclair wrote:
> L>Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
> Ага. И прощай <stdio>?
> L> Ибо это практически всегда ошибка дизайна.
> Да это ж гордость дизайна С++! Даймонд вперед всего применили именно в
> stdlib.
А где там оно используется?

Posted via RSDN NNTP Server 2.0

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

C>Sinclair wrote:
>> L>Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
>> Ага. И прощай <stdio>?
>> L> Ибо это практически всегда ошибка дизайна.
>> Да это ж гордость дизайна С++! Даймонд вперед всего применили именно в
>> stdlib.
C>А где там оно используется?

имеется ввиду наверное <iostream>. класс iostream наследуется от istream и от ostream, которые, в свою очередь, имеют общего предка ios.

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

C>>Но это детали, мне самому MH нравится так как позволяет использовать
C>>mixin'ы и ряд интересных приемов.

L>Согласен на 100%. МН это инструмент, который позволяет как плодить гибриды ежа с ужом, так и делать миксины которые ИМХО есть мегаудобный способ для того чтобы научить ежей плясать кадриль и ездить на велосипеде

.

Вот из-за таких как вы приходится неделями разбираться в коде где ежи на велосипедах ездют, хотя ето вообще не надо. Заглядывайте почаще в ветку Архитекрура ПО, Множественное наследование — это зло.
Кстате, полиморфизм — это не главная причина наследования, лучший полиморфизм достигается при помощи делегирования. Наследование только усиливает связь объектов, тем боллее множественное, а это в свою очередь приводит к усложнению отладки, расширения и вообще можно потеряться понимание того что пишешь. Я не говорю что наследование это плохо, просто применять надо грамотно.

Мои 2 копейки в защиту множественного наследования.

Ромбовидное наследование для реализации базового интерфейса "интрузивный подсчет ссылок"

есть альтернативы ?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS>Правильное использование наследования — это замещение (override) виртуальных функций. Только оно и ничего более. От этого есть безусловная польза, но это уже становится не наследованием, а специализацией. Поэтому я и говорю, что наследование как таковое является сомнительной концепцией. Какая-то она грязноватая эта концепция, с намешанными в одну кучу разными понятиями.

Да!
Только вот это уже не наследование называется, а ad-hoc полиморфизм.
В haskell еще кстати система типов так и устроена.

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

MS>>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету. Точнее есть, но она совсем из другой оперы.
N_C>Как это нету? А симбиоз организмов? Его можно рассматривать как некий механизм наследования.

Какой симбиоз?

симбиоз — это два разных класса, "живущих" в одном namespace

наследованием тут не пахнет.

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

M>Мои 2 копейки в защиту множественного наследования.

M>Ромбовидное наследование для реализации базового интерфейса "интрузивный подсчет ссылок"

M>есть альтернативы ?

Если бы таписал еще что это значит.

Al_>Какой симбиоз?

симбиоз — это два разных класса, "живущих" в одном namespace

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

vdimas wrote:
> C>Ну как бы оно тоже считается "статическим полиморфизмом".
> Офигеть.
> В этом случае все элементы статически-типизированных языков претендуют
> на статический полиморфизм.
> Например:
> operator+(int, int)
Нет, не все. Язык С (и всякие там Pascal'и, и не побоюсь этого слова,
Oberon) не поддерживают перегрузку методов.

То есть:

procedure DoBlah(var a : Integer);
procedure DoBlah(var a : SomeType);
procedure DoBlah(var a : String);

такой код там невозможен.

Posted via RSDN NNTP Server 2.0

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

M>>Ромбовидное наследование для реализации базового интерфейса "интрузивный подсчет ссылок"

L>Если бы таписал еще что это значит.

----- *.h ----
class irefference_counted
{
virtual ~irefference_counted(){}
public:
virtual int add_refference() = 0;
virtual int release() = 0;
};

class imy_cool_interface : public virtual irefference_counted
{
public:
virtual int do_cool_stuff() = 0;
};

class imy_cool_interface2 : public virtual irefference_counted
{
public:
virtual int do_cool_stuff2() = 0;
};

----- *.cpp ----

class base_refference_counted : public virtual irefference_counted
{
int count;
public:
int add_refference()
{
count++;
}

int release()
{
count--;
if(!count)
delete this;
}
};

class my_cool_interface_impl : public virtual imy_cool_interface, public virtual irefference_counted
{
......
};

class my_cool_interface_impl2 : public virtual imy_cool_interface2, public virtual irefference_counted
{
......
};

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Al_>>Какой симбиоз?

симбиоз — это два разных класса, "живущих" в одном namespace

наследованием тут не пахнет.
N_C>Ну, а если рассматривать полученный организм, как один? Или один внутри другого?
И вот опять мы вернулись к Канту

не... я бы все равно не стал наследовать.

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

M> ----- *.h ----
M>class ireference_counted
M>{
protected:
M>    virtual ~ireference_counted(){}
M>public:
M>    virtual int add_reference() = 0;
M>    virtual int release() = 0;
M>};

M>class imy_cool_interface : public virtual ireference_counted
M>{
M>public:
M>    virtual int do_cool_stuff() = 0;
M>};

M>class imy_cool_interface2 : public virtual ireference_counted
M>{
M>public:
M>    virtual int do_cool_stuff2() = 0;
M>};

template <class Base>
class ReferenceCounted : public Base
{
private:
  int refCount_;
public:
  ReferenceCounted() : refCount_(0) {}

  virtual int add_reference()
  {
    return ++refCount_;
  }

  virtual int release()
  {
    int result = --refCount_;
    if (0 == result) delete this;
    return result;
  }
};

M> ----- *.cpp ----

//M>class my_cool_interface_impl : public virtual imy_cool_interface, public virtual ireference_counted
class my_cool_interface_impl : public ReferenceCounted<imy_cool_interface>
M>{
M>......
M>};

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

Кё>>во-вторых, проводить аналогии с реальным миром значить ограничить сам себя, потому что в реальном мире "наследование" может иметь такие последствия, которые невозможны в вашем языке программирования, и наоборот, ваша реализация наследования в ЯП может давать такие эффекты, которых в реальном мире нет.

Al_>Категорически не согласен. Программирование должно быть... или нет, не "должно быть", а должно иметь возможность быть тесно связанным с тем миром для которого реализуется программный код.
Al_>В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.

см. выделенное.
Обычно не программируют живую природу

Я реализую код для автоматизации работы, скажем, операциониста в банке... И что, думаешь, он оперирует понятиями "объект" или "наследование"?
Нет.
Но это не мешает удобно представить сущности с которыми он реально работает в виде объектов

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS>>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету.

Т>Ну как же нету? Вот умирает дедушка и оставляет в наследство домик в деревне или там престол.

В классическом ООП-наследовании дедушка не умирает, и продолжает владеть царским престолом, хотя и передал его уже наследнику.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Кстати вы сами не чувстуете притиворечие ? В заголовочный файл интерфейса объекта вносится ИМПЛЕМЕНТАЦИЯ некого класаа.

То есть задача интерфейса во многом , удаление зависимостей между модулями , а внесение имплементации еще и в таком неестетичном виде , мягко говоря этой цели не соответствует .

А еслши класс имеет ОЧЕНЬ простой интерфейс и ОЧЕНЬ сложную реализацию ? на мой взгляд это противоречие.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Может, оставите свой менторский тон? Или Вы лично разбирались с моим кодом и имели к нему какие-то претензии? Я прекрасно знаю плюсы и минусы множественного наследования. Но вот таких безапеляционных заявлений претендующих на истину в последней инстанции себе не позволяю.

M>Кстати вы сами не чувстуете притиворечие ? В заголовочный файл интерфейса объекта вносится ИМПЛЕМЕНТАЦИЯ некого класаа.

Это недостаток C++ — реализацию шаблонных классов в общем случае нельзя вынести в cpp.

M>То есть задача интерфейса во многом , удаление зависимостей между модулями , а внесение имплементации еще и в таком неестетичном виде , мягко говоря этой цели не соответствует .

M>А еслши класс имеет ОЧЕНЬ простой интерфейс и ОЧЕНЬ сложную реализацию ? на мой взгляд это противоречие.

Такая ситуация обходится след. образом — делается нешаблонный класс, куда выносится вся имплементация, а уже шаблон от этого класса наследуется. Согласен, что это будет сильно смахивать на "наследование агрегацией" — поскольку каждый метод шаблона обязан будет явно вызывать метод нешаблонного класса-имплементации.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>vdimas wrote:
>> C>Ну как бы оно тоже считается "статическим полиморфизмом".
>> Офигеть.
>> В этом случае все элементы статически-типизированных языков претендуют
>> на статический полиморфизм.
>> Например:
>> operator+(int, int)
C>Нет, не все.

Например?

C>Язык С

Язык С — слабо статически типизирован. Например, он автоматом переводит все типы указателей друг к другу.

Вопрос остается. Мне считать operator+(int, int) проявлением статического полиморфизма?

(на всякий случай напомню мое мнение: статический полиморфизм — это сленг)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

vdimas wrote:
>> > В этом случае все элементы статически-типизированных языков претендуют
>> > на статический полиморфизм.
>> > Например:
>> > operator+(int, int)
> C>Нет, не все.
> Например?
Я же сказал, Паскаль — это статически типизированый язык (поспоришь?),
но в нем запрещена статическая перегрузка. То есть не может быть двух
функций с одним именем, но с разным набором параметров.

> Вопрос остается. Мне считать operator+(int, int) проявлением
> статического полиморфизма?
Да, если возможен operator +(MyObject,int).

> (на всякий случай напомню мое мнение: статический полиморфизм — это сленг)
Он упоминается в книгах Страуструпа, так что это уже термин

Posted via RSDN NNTP Server 2.0

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

C>Я же сказал, Паскаль — это статически типизированый язык (поспоришь?),
C>но в нем запрещена статическая перегрузка. То есть не может быть двух
C>функций с одним именем, но с разным набором параметров.

>> Вопрос остается. Мне считать operator+(int, int) проявлением
>> статического полиморфизма?
C>Да, если возможен operator +(MyObject,int).

Если в языке есть неявное приведение short int -> int, то оператор + (int, int) полиморфен. Но это не универсальный полиморфизм, а ad-hoc. Точно также как и перегрузка. Поэтому и Паскаль все-таки нельзя назвать полностью мономорфным языком.

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Кодёнок, Вы писали:

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

Кё>>>Какой физический смысл у массива любых объектов? Откуда такой странный опыт — массив, как людям удалось такое придумать?
Al_>>Да коробок спичек, например. НАБОР любых условно-ОДНОРОДНЫХ объектов. Вполне реальный объект.

Кё>Коробок спичек, это просто удобный частный случай. Расскажи лучше про смысл массива слонов, который необходим чтобы listview мог отобразить произвольную выборку индивидов.

В зоопарке есть N слонов, каждый со своим инвентарным номером. Даже где-то в бухгалтерии они значатся. А вообще я не любитель массивов — предпочитаю списки очереди и пр...

Кё>Или про массив всех спичек некоторого завода за 2005-й год, у которых отсутствует головка (брак). Где у них соответствующий реальный объект?
Ну приведу я тебе щаз пример... что это изменит? Ветку — в священные войны — там глядишь и народ подключится

Кё>>>Какой физический смысл у объектов-оберток? Что моделирует объект, который существует лишь из-за технического ограничения — часть кода должна была Al_>Не хотел бы я работать с такой системой. В ней черт ногу сломит.

Кё>А тебя не спрашивают, что бы ты хотел. Когда в системе есть библиотека А, которая использует std::string, и есть библиотека Б, которая использует MyFooString, тебе нужно написать пару "бессмысленных" функций и оберток чтобы их данные свободно передавались между объектами библиотек. Эти пара непонятных функций нужны чтобы остальные 90% системы сделать читабельными, прозрачными и понятными.
А представь, что у тебя 95% кода из таких "бессмысленных" функций

. Куда щемиться будешь?

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

От:	McSeem2	http://www.antigrain.com
Дата:	02.08.06 03:10
Оценка:	1 (1) +3 -9

	От:	fmiracle
	Дата:	02.08.06 19:03
	Оценка:	67 (8) +5

От:	Ramzes_	http://ramzes.ws/
Дата:	02.08.06 10:44
Оценка:	+6

От:	McSeem2	http://www.antigrain.com
Дата:	03.08.06 17:45
Оценка:	1 (1) +4

	От:	quadrochups
	Дата:	22.08.06 10:01
	Оценка:	-4

	От:	Кодёнок
	Дата:	02.08.06 11:02
	Оценка:	8 (2) +1 -1

	От:	sergey_mosyakov
	Дата:	02.08.06 06:00
	Оценка:	-4

	От:	last_hardcoder
	Дата:	02.08.06 06:16
	Оценка:	-3

От:	IT	linq2db.com
Дата:	02.08.06 03:29
Оценка:	+2

От:	dr.Chaos	Украшения HandMade
Дата:	02.08.06 08:59
Оценка:	+1 -2

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	03.08.06 14:07
Оценка:	+1

От:	Al_	нпкинтегра.рф
Дата:	15.08.06 02:20
Оценка:	-2

	От:	astral_marine
	Дата:	02.08.06 09:39
	Оценка:	1 (1)

От:	Mab	http://shade.msu.ru/~mab
Дата:	01.08.06 20:27
Оценка:	-1

От:	Whistler	Блог на GotDotNet.ru
Дата:	02.08.06 10:46
Оценка:

	От:	g_i
	Дата:	06.08.06 17:51
	Оценка:	+2

	От:	g_i
	Дата:	06.08.06 08:19
	Оценка:	+1

	От:	Cyberax
	Дата:	09.08.06 17:18
	Оценка:	+1

От:	Андрей Коростелев	http://www.korostelev.net/
Дата:	02.08.06 11:12
Оценка:

	От:	Андрей Хропов
	Дата:	05.08.06 12:12
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	10.08.06 20:53
Оценка:

	От:	граммофон
	Дата:	13.08.06 13:00
	Оценка: