Armanx64, речь шла об отсутствии множественного наследования. Про интерфейсы все знают
https://nolinux.w2c.ru - море баттхерта и деаонимизации
Неактивен
Мсье Armanx64, на этот предмет пытайте Linfan, когда он из Египта вернётся. Я не настолько в ООП разбираюсь. И без хамства, плиз.
https://nolinux.w2c.ru - море баттхерта и деаонимизации
Неактивен
И без хамства
Посмеялся
Хорошо смеётся тот кто смеётся последним
https://nolinux.w2c.ru - море баттхерта и деаонимизации
Неактивен
Ой, с нетерпением жду кого-нибудь, чтобы обсудить, что же дает такого множественное наследование , без чего в .нет что-то получается "кривее".
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Ой, с нетерпением жду кого-нибудь, чтобы обсудить, что же дает такого множественное наследование , без чего в .нет что-то получается "кривее".
Да че вы прицепились к этому множественному наследованию? От него в пользу интерфейсов отказались еще в Delphi периода Борланда и в D. Ну и?
А в интерпретируемых языках, наверно, так и не откажутся.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
От него в пользу интерфейсов отказались еще в Delphi периода Борланда и в D. Ну и?
А в интерпретируемых языках, наверно, так и не откажутся.
Да я сам не знаю, чего прицепились)
В С++ тоже, наверное, не откажутся (издал гомерический хохот)
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
В С++ тоже, наверное, не откажутся (издал гомерический хохот)
и правильно сделают. Хочется интерфейсов - используй множественное наследование только интерфейсов. Кто не даёт-то?
std::fstream на множественном наследовании построен - ну и чё?
и правильно сделают. Хочется интерфейсов - используй множественное наследование только интерфейсов. Кто не даёт-то?
std::fstream на множественном наследовании построен - ну и чё?
Да ниче) Я разве где-то говорил, что че?
Вообще все один хрен и приемы примерно те же.
Редактировался Tiphon (30-07-10 20:35:20)
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Потому, что это противоречит парадигме .NET: в любом пространстве имён дерево классов должно быть строго иерархическим, что бы всегда можно было подняться к предку, а не к предкам.
Какая похвала Борланду )))
Добавлено спустя 13 мин 48 с:
. А если вам нужны свойства более чем одного класса, то лучше создать интерфейс, более того, встроенный в VS2010 рефрактор на основе кода может сам создать интерфейс.
На самом деле это проще только для создателей компилятора, но не для программиста, который этим языком будет пользоваться.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
На самом деле это проще только для создателей компилятора, но не для программиста, который этим языком будет пользоваться.
Все не так просто и страшно. Все сложно. Никто по одному зайцу не стреляет. Например, при создании C# обращалось внимание так же и на сложность его парса. В отличии от С++ - C# парсится очень легко, поэтому есть возможность создавать замечательные инструменты, которых под C++ нет. (Конкретика - см. Resharper https://ru.wikipedia.org/wiki/ReSharper)
Ну на вскидку могу еще подбросить то, что с точки зрения производительности наследование классов характеризуется за борьбу - влезет у тебя все с потрахами в кеш или нет. Как раз неструкрутрированное наследование с виртульными функциями (т.е. с созданим виртульных таблиц) приводит к созможному уменьшению производительности С++. Имея разграничения можно легче оптимизировать данную проблему.
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Кто там трындел про отсутствие интерфейсов в .NET? Кажись, линьфань?
Цитирую из книги Джона Либерти:Кроме того, язык С# поддерживает интерфейсы (interfaces) - средст-
во заключения контракта с классом на предоставление услуг, огово-
ренных интерфейсом. В языке С# класс может наследоваться только
от одного родителя, но в нем могут быть реализованы несколько ин-
терфейсов. Реализуя интерфейс, класс обещает предоставить функ-
циональность, описанную интерфейсом.
ух ты, какую я ветку то пропустил, не посещая форум. Оказывается (k)Armanx64 тут
батхерт зализывал (я надеюсь правильно расшифровал твой ник? Косишь под Учителя? )
(k)Арманчик, прежде чем лезть в обсуждение таких вопросов, ты бы
базовые вещи по ООП освоил бы, да и не только по ООП. А то в соседнем треде
выяснилось, что ты не знаешь таких примитивных вещей как типы (если такое
выяснится при приеме на работу - тебя ни в одну контору не возьмут... ну разве что
толчки мыть ).
Касательно основного отличия между интерфейсами и множественным наследованием -
в интерфейсах "Реализуя интерфейс, класс обещает предоставить функ-
циональность, описанную интерфейсом." А при множественном наследовании класс
потомок получает готовый функционал от предков. Разницу поймешь
или надо на пальцах пояснять?
Редактировался Linfan (14-08-10 18:59:53)
"но в отличие от вас не стремлюсь здесь перед всеми показаться умнее всех"
"Ну здесь много мосек, что ж поделаешь."
"народ после общения со мной умнеет что ли, становится более бдительным в сети"
(с) Великий Человек
Неактивен
Множественное наследование приводит к путанице и нельзя найти конкретного родителя. Безупорядоченные половые связи опасны. wink
(k)Арманчик, вы непроходимо тупы и не шарите в теме чуть более чем полностью. Паренты декларируются в самом начале класса.
class MutiParents (Parent1, Parent2, Parent3):
def __init__(...):
и т.д.
Заявить такое - тоже самое сказать, что "интерфейсы приводят к путанице и нельзя найти конкретный интерфейс".
"но в отличие от вас не стремлюсь здесь перед всеми показаться умнее всех"
"Ну здесь много мосек, что ж поделаешь."
"народ после общения со мной умнеет что ли, становится более бдительным в сети"
(с) Великий Человек
Неактивен
Любое расширение возможностей потенциально повышает сложность, а значит и увеличивает и путаницу. Это цена, которую приходится платить.
100% Это верно для любого ЯП и для любого сложного проекта. В данном случае все зависит от создателей проектов.
Добавлено спустя 05 мин 46 с:
Наследование нужно, ибо ООП.
Множественное наследование нужно, когда два и более класса должны уметь делать что-то одно.
Но в случае других языков мне придётся делать два базовых класса, а затем наследовать от них свой производный.
В случае с .NET я знаю, что мне нужно. Максиум я наследую базовый класс - всё остальное в интерфейсе.
К примеру, я могу применить foreach к любому экземпляру класса, реализующего интерфейс IEnumerable.
Я могу создать интерфейс IВыключабл, и реализуя его в классах, я знаю, что все они могут иметь возможность выключения.
Всё просто.
Ты так и не понял основной сути - интерфейсы провоцируют дуплицирование кода, поскольку это отложенная имплементация. Именно благодаря языковым особенностям Питона (в т.ч. множественному наследованию) код проектов на Питоне на порядок компактнее чем на дотнете/жабе/плюсах. А соотв. скорость создания проекта гораздо выше и меньше людей нужно на его написание и поддержку. Чистый бизнес и никакой религии.
Редактировался Linfan (14-08-10 19:40:05)
"но в отличие от вас не стремлюсь здесь перед всеми показаться умнее всех"
"Ну здесь много мосек, что ж поделаешь."
"народ после общения со мной умнеет что ли, становится более бдительным в сети"
(с) Великий Человек
Неактивен
Нет, не понял тут кое что некто другой.
Код будет расти в любом случае. Интерфейсы гарантируют то, что даже несмотря на разность работы, разные классы смогут взаимодействовать по одним и тем же стандартам. Хотя да, кому я говорю...
(k)Арманчик, ты хочешь сказать что имплементация интерфейсов "гарантируют то, что даже несмотря на разность работы, разные классы смогут взаимодействовать по одним и тем же стандартам" а наследование не гарантирует??? Так, школота, иди читай учебники!
Можешь сходить в блог карманыча и поскоморошничать под моим ником - судя по-всему, ты так батхерт залечиваешь
"но в отличие от вас не стремлюсь здесь перед всеми показаться умнее всех"
"Ну здесь много мосек, что ж поделаешь."
"народ после общения со мной умнеет что ли, становится более бдительным в сети"
(с) Великий Человек
Неактивен