Цена МН
От: SV.  
Дата: 09.03.10 10:11
Оценка:
Навеяно веткой "[ООП] Хочу странного".

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

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

Так вот, а какова цена, предъявленная за наличие МН именно программисту? Допустим, в C# добавили бы МН, что бы мы неизбежно потеряли? Студия бы тормозила от повысившейся сложности?
множественное наследование
Re: Цена МН
От: fmiracle  
Дата: 09.03.10 14:52
Оценка: 4 (1) -1
Здравствуйте, SV., Вы писали:


SV.>Так вот, пытаясь сообразить, какова цена МН, понял, что все читанные мной дискуссии крутятся вокруг того, что МН позволяет наделать гадостей. Но ведь это цена, которую платит создатель языка, а не программист. Микрософту захотелось, чтобы язык пользовался репутацией надежного, и они поубирали оттуда все, что представляло опасность, в том числе, наследование. Но это именно цена, предъявленная Микрософту, потому, что программисты одной группы какого-нибудь ISV вполне могут просто договориться не пользоваться МН, и сам язык тут не при чем.


SV.>Так вот, а какова цена, предъявленная за наличие МН именно программисту?


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

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

В третьих — сложнее сделать компилятор, студию, средства поддержки рефакторинга => меньше хороших инструментов будет у программиста — это тоже его цена.

В четвертых, это использование сторонних библиотек, в котором программисты были подвержены пункту два (переоценка своих сил). И вроде на первый вглядт с библиотекой все хорошо, а потом в самый неподходящий момент оказывается какая-то проблема.
Или с библиотекой все хорошо. Может быть она даже самая лучшая в мире. Но ее использование предполагает МН. А программисты по п.1 договорились МН не использовать. Библиотека идет лесом. Тоже цена.

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


Как раз создателю спецификации-то цена введения МН не так и велика.

Вообще концепция "оставим что-то что может вызвать проблемы, потому что если кто захочет — сможет это не использовать" — она неправильна. Тот, у кого недостаточно опыта, чтобы понять, что может неправильно использовать данную технику — скорее всего не поймет, что у него недостаточно опыта и будет ее использовать. Запутанно выразился, но все правильно, я проверил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[2]: Цена МН
От: SV.  
Дата: 10.03.10 21:02
Оценка:
Здравствуйте, fmiracle, Вы писали:

Опять все то же: что можно понаделать гадостей. Может, хватит?

Заинтересовало только вот это:

F>В третьих — сложнее сделать компилятор, студию, средства поддержки рефакторинга => меньше хороших инструментов будет у программиста — это тоже его цена.


Нельзя ли поподробнее? Кроме линейного роста сложности (надо перебирать не 1 базовый класс, а сразу N), чем еще чревато МН?

Я, признаться, больше ждал ответов типа, с МН нельзя будет сделать того-то и того-то. Объективно и независимо от программиста.
Re[3]: Цена МН
От: vdimas Россия  
Дата: 11.03.10 03:24
Оценка:
Здравствуйте, SV., Вы писали:

SV.>Нельзя ли поподробнее? Кроме линейного роста сложности (надо перебирать не 1 базовый класс, а сразу N), чем еще чревато МН?


Ну, пофиг это перебирание, IDE спокойно "перебирает" все базовые интерфейсы, что есть разновидность множественного наследования.
Re[2]: Цена МН
От: vdimas Россия  
Дата: 11.03.10 03:54
Оценка:
Здравствуйте, fmiracle, Вы писали:

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


Столько букв, а на вопрос-то и не ответил. Вернее, ответил так, будто мы и сами знаем вред от МН, а мы как раз хотели услышать.


F>Во-первых, как ты сам сказал, ценой является необходимость договаривориться не использовать.


Зачем?

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


Так о каких проблемах речь? Ты используешь МН интерфейсов? Сильные проблемы?


F>В третьих — сложнее сделать компилятор, студию, средства поддержки рефакторинга => меньше хороших инструментов будет у программиста — это тоже его цена.


Такая же точно поддержка рефакторинга, как и при МН интерфейсов. Ты, похоже, не понимаешь, как эти инструменты работают.


F>В-пятых — поддержка и дальнейшее развитие. Изначально проект мог писаться человеком, который в МН прекрасно ориентируется и проблем не делает. А потом этот человек увольняется и поддержка проекта переходит к гораздо менее опытному разработчику. Вот он-то и расплатится по полной.


Чем именно? Почему этот более слабый специалист сможет работать с МН интерфейсов, но не сможет работать с МН реализаций?

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

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

Ну и напоследок, для управляемых языков проблема МН не в языке, а в платформе, ибо еще не придуман способ эффективной работы GC в случае множественного наследования.
Re[3]: Цена МН
От: FR  
Дата: 11.03.10 05:50
Оценка: +3
Здравствуйте, vdimas, Вы писали:


V>Ну и напоследок, для управляемых языков проблема МН не в языке, а в платформе, ибо еще не придуман способ эффективной работы GC в случае множественного наследования.


Не понятно в чем могут быть проблемы для GC при множественном наследовании.
Re[3]: Цена МН
От: fmiracle  
Дата: 11.03.10 09:35
Оценка:
Здравствуйте, SV., Вы писали:

SV.>Я, признаться, больше ждал ответов типа, с МН нельзя будет сделать того-то и того-то. Объективно и независимо от программиста.


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

Таким образом, при выборе средств приходится учитывать, с какими реальными людьми будешь работать сейчас и в будущем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[4]: Цена МН
От: vdimas Россия  
Дата: 11.03.10 13:26
Оценка:
Здравствуйте, FR, Вы писали:

V>>Ну и напоследок, для управляемых языков проблема МН не в языке, а в платформе, ибо еще не придуман способ эффективной работы GC в случае множественного наследования.


FR>Не понятно в чем могут быть проблемы для GC при множественном наследовании.


Да нет проблем, дело в эффективности, ибо в случае МП либо усложняется модель хранения объекта (напр. каждый базовый объект должен иметь ссылку на "реальный" объект самого верхнего уровня), либо меняется семантика управляемых ссылок. Сейчас сам объект — это единичный элемент для GC, и который может быть root, но в случае же множественного наследования, и наличия ссылок на базы, мы будем ссылаться куда-то внутрь данных объекта самого высокого уровня. Да, прямо сейчас похожий случай вполне отрабатывается через специальную пометку типа ссылки (в C# ее тип получается через модификаторы ref/out), в случае же МН, все ссылки станут такими же "специальными", что ИМХО скажется на эффективности GC.
Re: Цена МН
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 11.03.10 16:16
Оценка:
Здравствуйте, SV., Вы писали:

SV.>Так вот, а какова цена, предъявленная за наличие МН именно программисту? Допустим, в C# добавили бы МН, что бы мы неизбежно потеряли? Студия бы тормозила от повысившейся сложности?


Для начала, каким образом это МН было бы реализовано? Если взять за основу C++, то мне кажется, что эта идея обречена изначально на провал, так как сразу много кода, который работает с RTTI и берет там информацию об иерархии классов, вылетело бы в трубу. Не говоря уже о куче геморроя с тем, чтобы всякий раз решать конфликты с методами Object. Так что проще придумать другой язык.
Re[2]: Цена МН
От: SV.  
Дата: 11.03.10 18:54
Оценка:
Здравствуйте, Mystic, Вы писали:

SV.>>Так вот, а какова цена, предъявленная за наличие МН именно программисту? Допустим, в C# добавили бы МН, что бы мы неизбежно потеряли? Студия бы тормозила от повысившейся сложности?


M>Для начала, каким образом это МН было бы реализовано?


Каким? Самым лучшим из всех возможных. Если вы покажете, что при самых лучших вариантах мы что-то теряем, это будет отличным ответом на мой вопрос.

>Если взять за основу C++, то мне кажется, что эта идея обречена изначально на провал, так как сразу много кода, который работает с RTTI и берет там информацию об иерархии классов, вылетело бы в трубу.


Не понял. Если вы про то, что C# с МН будет несовместим с C# без МН, то кто б сомневался. Ну, пусть будет C##. Чем он будет хуже C#?

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


http://en.wikipedia.org/wiki/Diamond_problem

Мне нравится решение из C++.

***

Должен констатировать, что вопрос не был понят почти никем из отвечающих. Допустим, ломает нас "проперли квалифаить" ручками. Так не наследуйся и дело с концом. Вот если бы за счет разрешения делать МН у нас отпадал бы какой-нибудь фундаментальный механизм типа RAII...
Re[5]: Цена МН
От: rus blood Россия  
Дата: 14.03.10 09:53
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Да нет проблем, дело в эффективности, ибо в случае МП либо усложняется модель хранения объекта (напр. каждый базовый объект должен иметь ссылку на "реальный" объект самого верхнего уровня), либо меняется семантика управляемых ссылок. Сейчас сам объект — это единичный элемент для GC, и который может быть root, но в случае же множественного наследования, и наличия ссылок на базы, мы будем ссылаться куда-то внутрь данных объекта самого высокого уровня. Да, прямо сейчас похожий случай вполне отрабатывается через специальную пометку типа ссылки (в C# ее тип получается через модификаторы ref/out), в случае же МН, все ссылки станут такими же "специальными", что ИМХО скажется на эффективности GC.


А что, при использовании только единичного наследования, ссылка по-твоему не может попасть "внутрь данных объекта самого высокого уровня"?
Имею скафандр — готов путешествовать!
Re[6]: Цена МН
От: vdimas Россия  
Дата: 14.03.10 15:36
Оценка:
Здравствуйте, rus blood, Вы писали:

RB>А что, при использовании только единичного наследования, ссылка по-твоему не может попасть "внутрь данных объекта самого высокого уровня"?


Да, прямо сейчас похожий случай вполне отрабатывается через специальную пометку типа ссылки (в C# ее тип получается через модификаторы ref/out), в случае же МН, все ссылки станут такими же "специальными", что ИМХО скажется на эффективности GC.

Re[2]: Цена МН
От: SergeyT. США http://sergeyteplyakov.blogspot.com/
Дата: 14.03.10 17:24
Оценка:
Здравствуйте, fmiracle, Вы писали:

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


F>В третьих — сложнее сделать компилятор, студию, средства поддержки рефакторинга => меньше хороших инструментов будет у программиста — это тоже его цена.


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

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

P.S. Если подходить бездумно, то в каждом языке существует множество способов отстрелить себе ногу и мне кажется, что множественное наследование не является самым опасным механизмом в этом плане.
Re[3]: Цена МН
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.03.10 18:22
Оценка:
Здравствуйте, SergeyT., Вы писали:

ST> Но это же не повод отказываться и от одиночного наследования тоже?


А может быть и вполне себе повод. Соседний топик читал?

ST>P.S. Если подходить бездумно, то в каждом языке существует множество способов отстрелить себе ногу


Они, эти способы, далеко не идентичны в этом плане.

ST> и мне кажется, что множественное наследование не является самым опасным механизмом в этом плане.


Одним из самых опасных. Одиночное тоже.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
AVK Blog
Re[2]: Цена МН
От: 0x7be СССР  
Дата: 15.03.10 07:21
Оценка:
Здравствуйте, fmiracle, Вы писали:

F>Во вторых, это скрытая проблема переоценки своих сил. Программисты некоей компании не договариваются неиспользовать МН, потому что у них-то никогда не может быть пробем, они же самые лучшие программисты в мире. А потом получается куча зарытых проблем (потому что не такие уж они и наилучшие). Но договариваться неиспользовать уже поздно — на поддержке 3 системы с глубоко закопанными проблемами.

Любой инструмент можно использовать неправильно, злоупотребить им. Чем МН такое особенное по отношению к другим свойствам языка?
Re[3]: Цена МН
От: 0x7be СССР  
Дата: 15.03.10 07:34
Оценка:
Здравствуйте, SV., Вы писали:

SV.>Не понял. Если вы про то, что C# с МН будет несовместим с C# без МН, то кто б сомневался. Ну, пусть будет C##. Чем он будет хуже C#?

Неправильно! Это будет C#++
Re[3]: Цена МН
От: fmiracle  
Дата: 15.03.10 08:32
Оценка: +1
Здравствуйте, SergeyT., Вы писали:

ST>Кстати, в этом вопросе очень интересно мнение Мейера, но не как теоретика (и автора одной из самых авторитетных книг по ООП), а как практика, автора языка программирования Eiffel и среды разработки Eiffel Studio.

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

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

Поэтому, поддержка возможности Х скорее всего приведет к худшей поддержке возможностей У и Z. Либо IDE выйдет попозже.

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

Это и есть цена для программиста про которую спрашивал топик-стартер. Что у него под данным языком либо вообще нет IDE, либо она не дописана. Когда-нибудь в светлом будущем она будет, да...

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

Заметим в скобках, что IDE и компилятор, и прочие тулы, ведь не обязательно должен делать разработчик языка, могут и сторонние. Если они смогут для данного языка сделать что-то приличное. Или предпочтут сделать что-то приличное для другого языка В результатет опять программисты более простого языка скорее получат больший и более качественный инструментарий.



Кстати, я не разрабатываю ни IDE, ни компиляторы, и не знаю насколько сложно будет поддержать именно МН. Но я твердо знаю — любая новая возможность — это всегда ресурсы, которые надо откуда-то взять.


ST>Вообще, у меня сложилось впечатление, что вы несколько переоцениваете сложности множественного наследования. Ведь я думаю, что вы и сами прекрасно знаете, какие сложности при поддержке и развитии кода возникают при _неумелом_ использовании одиночного наследования. Многие молодые разработчики "переоценивают" мощь наследования, неправильно понимаю его сильные и слабые стороны, и суют его во все дыры, в результате возрастает связность, появляются такие клубы, которые распутать становится весьма сложно. Но это же не повод отказываться и от одиночного наследования тоже?


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

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

Кадры, как обычно, решают все. Были бы все программисты уровня как Страуструп и Майер — так и с МН вообще никаких бы проблем не было, думаю
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.