![]() |
Множественное наследование
Хочу наследоваться от нескольких классов. Бред?
Класс наследуется от MovieClip. А если я хочу еще EventDispatcher добавить, что бы мой объект и клипом был и события свои отправлял? |
Множественного наследования нет. Но на ваше счастье MovieClip уже наследует EventDispatcher.
|
MovieClip и так является EventDispatcher'ом.
|
Спасибо. Не знал. )
А все-таки, как решать проблему, если мне нужен функционал нескольких классов? Организовывать владение экземплярами этих классов? |
Цитата:
|
В примере с EventDispatcher можно через реализацию интерфейса IEventDispatcher добиться желаемого.
|
Цитата:
|
Зато в AS3 есть множественное наследование для интерфейсов, вот только имплементить интерфейс прикрученый к классу нельзя :(
|
Цитата:
|
Класс по-сути состоит из двух частей: интерфейс и реализация. Т.е. в других языках, на сколько я знаю в той же яве можно имплементить другой класс, т.е. пример (псевдокод):
Код AS3:
Код AS3:
|
Цитата:
|
Ну тогда не помню где, но где-то видел такое :)
|
Цитата:
Плюс реализовывать надо даже скрытые поля. Вобщем, пользы маловато. |
Цитата:
|
Частично задачу можно решить использую интерфейсы и композицию. Но возможно оно и к лучшему, что множественного наследования нет, ускоряя генерирование функционала, оно может значительно усложнить код.
|
Композиция рулит. Поверьте, множественное наследование это зло, и java и c# не случайно от него отказались.
Вначале это может казаться прикольным... Но потом может привести к страшному бардаку... В общем зачастую компаниях запрещено использовать множественное наследование даже на c++ |
Цитата:
Цитата:
Цитата:
Если судить по такой логике, можно обойтись вообще без наследования, только включая – что иногда приходилось делать в AS1. |
"Это приводит нас ко второму правилу объектно-ориентированного программирование: предпочитайте композицию наследованию классов"(с) Банда четырех.
Вообще почитайте "Приемы объектно ориентированного проектирование - паттерны проектирования". Глава введение, раздел "наследования и композиция". Хотя, конечно, дело вкуса, и каждый волен поступать так, как ему больше нравится... Но я не думаю, что от множественного наследования отказались только потому, что оно слишком сложно... Как минимум слишком неоднозначно, как должен работать полиморфизм, если в 2 родительских классах есть виртуальные методы с одинаковой сигнатурой. А для архитектуры и наглядности - это очень, очень плохо, имхо. Это как математике, главное не запомнить формулу, а понимать ее логику... А тут получается нет логики, а только формула. В результате программист зависит не от логики, а от реализации компилятора... |
А мне было бы круто просто наследовать от EventDispatcher`а вторым классом, чем реализовывать IEventDispatcher.
|
Покажите, пож., пример реализации IEventDispatcher. В хелпе непонятно как-то ((.
|
Показываем:
Код AS3:
|
Цитата:
Задача: "Человек - наследник безмозглой обезьяны. У него есть мозг". Реализация в таком вот подходе: "Человек - оболочка с обезьяной внутри. Плюс у него есть мозг". Реализация в подходе наследования: "Человек – следующие звено в развитии обезьяны. У него есть мозг." По-моему, второе звучит более логично. Привожу сравнительную характеристику собственного производства. «Наследование-включение»: «+» 1. Возможность реализовывать функции-провайдеры в наследнике («Декоратор»). Таким образом мы можем запретить к использованию некоторые методы отца (Тут следует заметить, что то же самое можно реализовать и в подходе наследования, но в таком случаи это будет менее естественно для данного подхода). 2. Можно множественно наследовать там, где множественно наследовать нельзя. «-» 1. Минус - громоздкий код («Декоратор» всегда громоздок). 2. Уничтожение одного из подходов к построению логики кода. Таким образом мы не сможем никак выделить архитектурой родственность между объектами. «Наследование-наследование»: «+» 1. Реализует стандарт С++. 2. Изящно – нет лишнего кода. 3. Минус один уровень вызова через точку. «-» 1. Сложно представить. При неправильном подходе может вызвать захламлённость структуры. 2. Требует умения думать абстрактно. Цитата:
Цитата:
Думаю, Страуструп дураком не был. |
Цитата:
|
А кто это?
Через некоторое время: Почитал. Ясно... А какова их мотивация? |
Вы тут описывали нам Декоратор. Так вот он тоже с приставкой GoF.
|
Цитата:
второй минус - иерархия классов чаще выглядит как граф, а не как дерево и не вписывается в одиночное наследование (про множественное ничего не знаю), третий минус - невозможность динамически изменять дерево наследования (ну это, если требуется) А разработчики as3 видимо посмотрели на Java, С#, D, ... и решили что и as3 без множественного наследования обойдется Считается что оно проблемы создает |
Пример реализации EventDispacher с помощью композиции:
Удалил, потому что пример был выше, просто чет не заметил его... P.S. На написание ушло не более 1 минуты... Медленнее чем просто унаследоваться, но не так уже и страшно... Добавлено через 7 минут Цитата:
|
Имхо множественное наследование - это геморрой)))
Видимо я не один такой. С множественным наследованием в разы проще запутаться в своей же иерархии. Интерфейсы многое решают, единственное что меня смущает в интерфейсах - я должен в любом случае переопределять заявленные в интерфейсе методы. Т.е. интерфейс он типа как просто обязалово для разраба, мол хочь не хочь, а вот этот набор методов ты должен описать, раз уж интерфейс имплементируешь. В остальном же - я не знаю ситуаций где множественное наследование уж настолько необходимо, гораздо проще для понимания именно композиция, та и пользоваться удобнее, пофиг что лишняя точка в имени метода/параметра появляется. Добавлено через 1 минуту И вся ветка кажись завязалась вокруг диспатчера, с ним вообще проблем не вижу, та и примеров накидали кучу уже. |
Цитата:
|
JackFromChaos, зачем писать точно такой же код, если он уже написан в посте номер 21?
|
Цитата:
|
у вас существенное упущение - не хватает this'а. Должно быть так:
Код AS3:
|
Цитата:
|
Конечно понял, просто сразу прояснил ситуацию ;)
|
Хорошо. Объясняю откуда взялась такая приверженность к множественному наследованию.
Пусть у нас есть большой проект (нам всё равно, какую иерархию он имеет, но он ОЧЕНЬ большой). В определённый момент возникает необходимость сделать графический трасировщик (box2d в тестовом режиме). При этом хочется, чтобы трасировщик оставался в парадигме дисплейных списков (иерархичность тестового отображения, родительские отображения передаются в детей, а главный класс иерархии передаёт всё дерево на сцену). Выход... Создаём класс (если бы делал на С++, объявил его виртуальным) с функцией Код AS3:
Но тут оказывается, что множественного наследования нет! Не выйдет передавать базовый трасировщик как папу-класс. Как папу-интерфейс – можно, но что тогда делать со спрайтом? В интерфейс-то переменные совать нельзя!.. Тащить его по всей структуре, совать в наследников? Засорять private-секцию всех объектов системы? Ладно, свойство одно, а если их пять? Если десять? Тоже везде заново писать в код наследников? Ладно, такой класс один!.. А если много? Например, у нас, в нагрузку ко всему прочему, есть класс, описывающий стандартный объект иерархии. Какой-нибудь CHierarchical? У него есть поле parent. Можно тоже обойтись без класса, но при этом поле снова-таки попадает в наследников… Дурная, надо сказать, наследственность. Короче, я красивого выхода из подобной ситуации не вижу. Может кто-то подскажет? Добавлено через 23 минуты Так. Попробовал реализовать. Не учёл, что описать вынесенные в наследника свойства надо будет только один раз, потом они будут переходить к наследникам, если описать его как protected. Будет легче, чем думал, но тоже не мёд, если честно. Но я уже не уверен, что был сто процентов прав... Добавлено через 1 час 4 минуты Всё. Переделал... Однако, код мне начинает нравиться, он стал более управляемым! Но тут как в игре в пинг-понг - повышаешь управляемость, но теряешь в скорости игры. Код стал более громоздким и в нём стали весомее комментарии. В общем, так как-то: Код AS1/AS2:
|
Это вы сейчас кому разговариваете слова? Вы поняли зачем нужны интерфейсы?
|
Вот в Вашем примере это решается одним интерфейсом, ITraceable.
|
Цитата:
Те комментарии, которые описаны у меня ДОЛЖНЫ БЫТЬ в коде, они должны предварять код, который описывают. Иначе код станет нечитабельным и вообще ужасным. Использование такого подхода - акт отчаяния. Другого выхода в языках, где отсутствует множественное наследование попросту не вижу. Включение - не выход. Там, где логика базируется на наследовании, включение будет суррогатом похлеще предложенного. Да и, кстати, описанный подход к формату будет действенным только для первого уровня иерархи. В более сложной ситуации - когда необходимы наследники от не корневых классов - он не поможет. Останется только композиция. (Могу показать картинку, не не понял как её вставлять сюда). Добавлено через 1 минуту Цитата:
|
Цитата:
|
Цитата:
|
| Часовой пояс GMT +4, время: 23:48. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.