![]() |
DisplayObjectContainer как на его основе написать класс?
Ну вот всем известно что Sprite наследуется от DisplayObjectContainer, а Shape от DisplayObject, но вот как самому написать свой класс что бы его можно было еще и выводить на экран наследуясь только от DisplayObject или DisplayObjectContainer?
Я знаю что эти классы абстрактные, но как всё-таки был написан Shape? |
Ничего непонятно. В чем проблема сделать extends DisplayObjectContainer например и получить свой собтсвенный спрайт?
|
Его потом методом addChild добавить нельзя.
|
Чем спрайт-то не нравится? И рисуется, и добавляется...
|
Дело не в том нравится или нет, а в том что я хочу понять природу создания ХД
|
|
Нельзя наследоваться от DisplayObject или DisplayObjectContaner, расширяйте спрайт, шейп или мувиклип.
|
Цитата:
|
Хелп:
Цитата:
Цитата:
Очень хочется надеяться, что в каком-нибудь AS4 (а лучше просто в новом плеере) появится новый класс контейнера, у которого addChild() будет protected — захотел, сделал в наследнике API для добавления в этот контейнер детей (причем нужного типа), не захотел — не сделал. То есть та мутация, которую на низком уровне произвели с TextField и SimpleButton: вроде бы контейнер, а публично добавить addChild'ом ничего нельзя. |
можно запретить вызовы addChild и т.д. для этого есть соотвествующие метатеги
|
Что мешает оверрайдить методы спрайта унаследовавшись от него?
|
Код в студию?
|
Код AS3:
|
Цитата:
Код AS3:
|
Цитата:
Нет, хочу Класс - закрытый контейнер. Final Hope, а теперь добавьте свой суперспрайт в список отображения. |
@Wolsh, метод запрещен, не пропустит компилятор его
|
Цитата:
Код AS3:
Цитата:
|
Код AS3:
Цитата:
|
Код AS3:
|
И это самое близкое к теме решение, которое, к сожалению, во-первых будет постоянным источником ошибок, а во-вторых так и не дает желанную типизацию аргумента.
|
Ну примерно таким путем старлинг пошел.
Имена те же - результат работы другой. Бесит. Поэтому я за композицию или наследование с добавлением других методов с другими именами. |
Цитата:
Цитата:
|
Final Hope, не переходите на зыбкую почву терминологии личностных оценок и скользкие трактовки сказанного другими.
|
И все таки, как же создали класс Shape? Или может у него интерфейсы какие есть?
|
Bletraut, Shape не имплементирует никаких интерфейсов. Написан он, как я понимаю на c++(поправьте, если ошибаюсь), как и все остальные встроенные классы as3 api.
|
Для чего же тогда было создавать DisplayObject? Только для того чтобы в методах указывать тип переменной?
|
Цитата:
Это же намного легче, чем для каждого нового дисплейного класса создавать те же самые функции и переменные. И вообще, он обхватывает все спрайты, шейпы, мувиклипы и это намного понятнее: Код AS3:
Код AS3:
Код AS3:
|
- чтобы не писать несколько раз один и тот же код, который можно унаследовать;
- полиморфизм; -??? |
И вообще, зачем вам "писать класс на основе DisplayObjectContainer"?
Вам дали Sprite/Shape/MovieClip - пользуйтесь. |
Цитата:
|
Цитата:
|
Цитата:
Цитата:
|
Цитата:
Код AS3:
|
MikroAcse, терпения не хватило переписать ВСЕ методы ДОКа? Там еще много-много вкусняшек, getChildAt(), getChildByName(), numChildren, tabChildren, mouseChildren, contains(), getChildIndex(), getObjectsUnderPoint(), setChildIndex(), swapChildren(), swapChildrenAt().
А теперь представь ту же ситуацию: некто видит что это Спрайт, пихает туда своё чадо и начинает с ним работать как ни в чем ни бывало. Компилятор молчит: вызов методов и свойств абсолютно законный. А в рантайме ошибка едет на ошибке и ошибкой погоняет. Флэш уже пять лет живет с AS3, и все ништяк. Никто не говорит, что это ужасный баг, который похоронит технологию. Никто не говорит, что надо все бросать и вешать на каждый спрайт по менеджеру. Речь о красоте, как бы пафосно это ни звучало. О том, что Спрайт просто мегаизбыточен. У него полтора десятка публичных методов, убивающих накорню всякую инкапсуляцию. Методов, в 95% случаев не нужных вообще извне. Все они должны быть закрыты так, чтобы при необходимости вы могли создать общий доступ в наследнике. Но не открытый доступ по-умолчанию же! Вы когда класс пишете, старательно закрываете доступ ко всем его внутренностям. Приватные свойства, приватные функции. И только один-два метода сознательно(!) делаете публичными. А в это время Я хочу, чтобы этих публичных свойств и методов НЕ БЫЛО вообще, в принципе. Хочу ДО, который "снаружи" не является контейнером вообще, но внутри дает полное API для работы с собственным списком отображения. Все публичные доступы я смогу написать сам. Мне это понадобится раз в полгода и займет четыре строчки, не родив ни одной ошибки. |
... А зачем? :)
Что это за перестраховка от атомных взрывов? Когда я писал только на as3 я тоже болел чем-то таким. Ошибка в рантайме при дебаге – вполне обычная ситуация. В 9 из 10 случаев эта ошибка не произойдёт если проэксклудить "лишние" с автокомплита. Сразу будет видно, что дёргать. В 1 из 10 случаев словить РТЕ – ну вот совсем не страшно. В Ruby или Python'е можно вообще приватные методы дёргать через :send. И дёргают, и живут, и код настолько красив и отDRYен, что такого в AS3 и встретить нельзя. Красота – это прекрасно и чудесно. Только это всё таки просто код. |
Цитата:
Цитата:
|
Wolsh, я представляю, что мог бы написать про избыточность UI :)
|
Да весь AS избыточен. В топку его. Машинный код - за ним будущее!
|
Согласен с Wolsh, что избыточность методов чисто морально напрягает. Там ещё эвент диспетчер не всегда нужен. Но на практике это не приносит проблем, а иногда даже полезно. Вот недавно возился с minimalComps компонентами, пришлось в одном случае сверху насильно выдрать маску из компонента.
|
Цитата:
Давай серьезно и без деградарующих примеров других языков? А то получается так: был AS1 и все торчало наружу. Появился AS2 и народ обрадовался, что есть классы, типизация, модификаторы доступа (хотя до private можно было легко достучаться через ['имя']). Появился AS3, народ от счастья с ума сходит от возможностей. Но проходит время и Psycho Tiger по сути говорит, что мы мучаемся и надо писать в стили AS1. Собственно, Wolsh излагает то, о чем я ему душу изливал недели две назад. Я был страшно недоволен отсутствием примитивного контейнера для компонентов. Это не болезнь, это желание иметь законченный и целостный компонент. И не перестраховка от атомных взрывов, а защита от дурака. Я хочу быть уверенным, что мой компонент случайно не сломают добавив туда что нить через addChild. Или что загрузив в компонент свой спрайт, не сломают компонент через parent. И если поломки через addChild и тп, можно защитится через переопределение. То из-за parent придется переопределять все. А можно забить. Или же все реализовать в FP примитивный контейнер, где почти все методы и свойства protected и по необходимости делать реализацию для public. Плохо от этого точно не было бы. |
| Часовой пояс GMT +4, время: 10:47. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.