Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   DisplayObjectContainer как на его основе написать класс? (http://www.flasher.ru/forum/showthread.php?t=200795)

Bletraut 07.06.2013 14:15

DisplayObjectContainer как на его основе написать класс?
 
Ну вот всем известно что Sprite наследуется от DisplayObjectContainer, а Shape от DisplayObject, но вот как самому написать свой класс что бы его можно было еще и выводить на экран наследуясь только от DisplayObject или DisplayObjectContainer?

Я знаю что эти классы абстрактные, но как всё-таки был написан Shape?

in4core 07.06.2013 14:17

Ничего непонятно. В чем проблема сделать extends DisplayObjectContainer например и получить свой собтсвенный спрайт?

Bletraut 07.06.2013 14:24

Его потом методом addChild добавить нельзя.

Final Hope 07.06.2013 14:24

Чем спрайт-то не нравится? И рисуется, и добавляется...

Bletraut 07.06.2013 14:30

Дело не в том нравится или нет, а в том что я хочу понять природу создания ХД

Final Hope 07.06.2013 14:41

http://help.adobe.com/ru_RU/ActionSc...0204-7f3f.html

Tails 07.06.2013 15:24

Нельзя наследоваться от DisplayObject или DisplayObjectContaner, расширяйте спрайт, шейп или мувиклип.

Psycho Tiger 07.06.2013 15:49

Цитата:

Сообщение от in4core (Сообщение 1136858)
Ничего непонятно. В чем проблема сделать extends DisplayObjectContainer например и получить свой собтсвенный спрайт?

У меня не получается :(

Wolsh 07.06.2013 16:11

Хелп:
Цитата:

Сам класс DisplayObject не содержит API-интерфейсов для визуализации содержимого на экране
, ну а вам-то удастся их добавить?))) Дисплейные классы реализованы в плеере. То есть именно предоставляют нам API — интерфейс для отображения чего-то на экране. Интерфейс нам доступен, а реализация, конечно же, нет. Так что создать свой собственный ДО невозможно.
Цитата:

Чем спрайт-то не нравится?
Да много чем. Какой-бы свой класс вы от него ни унаследовали, любой идиот может запихать в него что угодно методом addChild(). Вот вы пишете галерею, и делаете в ней метод addImage() для добавления изображений. В этом методе вы регистрируете картинку в массиве, привязываете к ней данные и размещаете в соответствии с общей сеткой-лейаутом. Но при этом снаружи ничего не стоит засунуть в эту "галерею" любой ДО бульварным addChild(), со всеми вытекающими. Безо всякой регистрации и безо всякого контроля над ним со стороны галереи. А ведь по сути практически всегда, когда вы пишете наследника Спрайта, вы предполагаете добавлять в него только совершенно определенные объекты и никогда не думаете делать это ИЗВНЕ методом addChild(). В 65% случаев все внутренние объекты создаются самим этим классом ВНУТРИ, и в 30% — добавляются извне через специальный публичный метод, содержащий фильтр Типа добавляемого объекта, и берущий его "на контроль", прежде чем добавить в свой список отображения.
Очень хочется надеяться, что в каком-нибудь AS4 (а лучше просто в новом плеере) появится новый класс контейнера, у которого addChild() будет protected — захотел, сделал в наследнике API для добавления в этот контейнер детей (причем нужного типа), не захотел — не сделал. То есть та мутация, которую на низком уровне произвели с TextField и SimpleButton: вроде бы контейнер, а публично добавить addChild'ом ничего нельзя.

СлаваRa 07.06.2013 16:18

можно запретить вызовы addChild и т.д. для этого есть соотвествующие метатеги

Dukobpa3 07.06.2013 16:22

Что мешает оверрайдить методы спрайта унаследовавшись от него?

Wolsh 07.06.2013 16:34

Код в студию?

СлаваRa 07.06.2013 16:38

Код AS3:

[Exclude(name="addChild",kind="method")]
[Exclude(name="addChildAt",kind="method")]
[Exclude(name="removeChild",kind="method")]
[Exclude(name="removeChildAt",kind="method")]
[Exclude(name="getChildAt",kind="method")]
[Exclude(name="getChildByName",kind="method")]
[Exclude(name="getChildIndex",kind="method")]
[Exclude(name="setChildIndex",kind="method")]
[Exclude(name="swapChildren",kind="method")]
[Exclude(name="swapChildrenAt",kind="method")]
[Exclude(name="contains",kind="method")]
 
public class Animation extends Sprite implements IAnimation {
  ...
  [Deprecated(message="метод запрещен")]
  public override function addChild(child:DisplayObject):DisplayObject {
    return null;
  }
  ...
}

вызвав, например, addChild, вы даже скомпилироваться не сможете

Final Hope 07.06.2013 16:46

Цитата:

Сообщение от Wolsh (Сообщение 1136899)
любой идиот может запихать в него что угодно методом addChild().

Использовать стандартные методы - это не идиотизм. А вот если вы, как разработчик класса, не позаботились о подобных проблемах, то это уже ваша вина, а не того, кого вы назвали идиотом.
Код AS3:

package
{
        import flash.display.Bitmap;
        import flash.display.Sprite;
 
        public class MySuperSprite
        {
                private var _sprite:Sprite;
 
                public function MySuperSprite()
                {
                        _sprite = new Sprite();
                }
 
                public function addImage( image:Bitmap ):void
                {
                        // Красиво раскладываем картинки на спрайте.
                }
        }
}


Wolsh 07.06.2013 16:48

Цитата:

вы даже скомпилироваться не сможете
Возможно, если буду вызывать его у :Animation )) Но он так и остался типом Sprite, и если переменная будет спрайтом, компилятор скромно промолчит. А что будет в рантайме?
Нет, хочу Класс - закрытый контейнер.

Final Hope, а теперь добавьте свой суперспрайт в список отображения.

СлаваRa 07.06.2013 16:50

@Wolsh, метод запрещен, не пропустит компилятор его

Final Hope 07.06.2013 16:55

Цитата:

Сообщение от Wolsh (Сообщение 1136911)
Final Hope, а теперь добавьте свой суперспрайт в список отображения.

Код AS3:

package
{
        import flash.display.Bitmap;
        import flash.display.DisplayObjectContainer;
        import flash.display.Sprite;
 
        public class MySuperSprite
        {
                private var _sprite:Sprite;
 
                public function MySuperSprite()
                {
                        _sprite = new Sprite();
                }
 
                public function addImage( image:Bitmap ):void
                {
                        // Красиво раскладываем картинки на спрайте.
                }
 
                public function addToContainer( container:DisplayObjectContainer ):void
                {
                        container.addChild( _sprite );
                }
        }
}

Цитата:

var mss:MySuperSprite = new MySuperSprite();
mss.addToContainer( this );
Wolsh, что ещё у вас не получается? :) Удаление? Перемещение?

Wolsh 07.06.2013 16:56

Код AS3:

var a:Sprite = new Animation();
a.addChild(b);

Компилятор, который это не пропустит, мне тоже не нужен.

Цитата:

Wolsh, что ещё у вас не получается?
ООП не получается. Вы сделали некий менеджер для спрайта, применив паттерн Фасад. Похвально, наверно, но речь то была о своем DisplayObject, а не мультиклассовых конструкциях для ограничения функциональности. Посмотрите на SimpleButton или TextField. Подумайте еще раз, о чем речь.

Dukobpa3 07.06.2013 17:01

Код AS3:

                override public function addChild($do:DisplayObject):DisplayObject
                {
                        if (!($do is IMyInterfaceForSprite)) return null;
 
                        else return super.addChild($do);
                }

@СлаваRa, ох уж эти хирурги. Всё бы им отрезать. Вот выпейте таблеточку, само отвалится.

Wolsh 07.06.2013 17:07

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

Dukobpa3 07.06.2013 17:09

Ну примерно таким путем старлинг пошел.
Имена те же - результат работы другой. Бесит.

Поэтому я за композицию или наследование с добавлением других методов с другими именами.

Final Hope 07.06.2013 17:16

Цитата:

Сообщение от Wolsh (Сообщение 1136914)
Подумайте еще раз, о чем речь.

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

Сообщение от Wolsh (Сообщение 1136914)
ООП не получается.

"У меня ООП не получается, поэтому я отнаследуюсь от спрайта и буду всех, кто в моих спрайтах использует addChild называть идиотами." :) Как это мило.

mooncar 07.06.2013 17:22

Final Hope, не переходите на зыбкую почву терминологии личностных оценок и скользкие трактовки сказанного другими.

Bletraut 07.06.2013 17:40

И все таки, как же создали класс Shape? Или может у него интерфейсы какие есть?

illuzor 07.06.2013 17:59

Bletraut, Shape не имплементирует никаких интерфейсов. Написан он, как я понимаю на c++(поправьте, если ошибаюсь), как и все остальные встроенные классы as3 api.

Bletraut 07.06.2013 18:34

Для чего же тогда было создавать DisplayObject? Только для того чтобы в методах указывать тип переменной?

MikroAcse 07.06.2013 18:48

Цитата:

Для чего же тогда было создавать DisplayObject? Только для того чтобы в методах указывать тип переменной?
Чтобы сделать класс, который имеет набор нужных абстрактный функций и переменных.
Это же намного легче, чем для каждого нового дисплейного класса создавать те же самые функции и переменные.
И вообще, он обхватывает все спрайты, шейпы, мувиклипы и это намного понятнее:
Код AS3:

var d:DisplayObject = array[i];
d.visible = false;

Чем это:
Код AS3:

var d:* = array[i];
d.visible = false;

Или это:
Код AS3:

var d:Object = array[i];
d['visible'] = false;


illuzor 07.06.2013 18:50

- чтобы не писать несколько раз один и тот же код, который можно унаследовать;
- полиморфизм;
-???

MikroAcse 07.06.2013 18:51

И вообще, зачем вам "писать класс на основе DisplayObjectContainer"?
Вам дали Sprite/Shape/MovieClip - пользуйтесь.

in4core 07.06.2013 19:34

Цитата:

Его потом методом addChild добавить нельзя.
Ну еп, откудаж я должен помнить что они файнал.

Bletraut 07.06.2013 19:44

Цитата:

И вообще, зачем вам "писать класс на основе DisplayObjectContainer"?
Вам дали Sprite/Shape/MovieClip - пользуйтесь.
А если я хочу закрытый контейнер?

Wolsh 07.06.2013 20:10

Цитата:

Для чего же тогда было создавать DisplayObject? Только для того чтобы в методах указывать тип переменной?
Не просто в методах, а в методах Списка Отображения, реализованных в плеере ("на с++"))) Это как интерфейс-метка IBitmapDrawable. Метка, что с этим объектом можно делать то-то и то-то. Ну и прицепом набор стандартных свойств типа ширины и высоты.
Цитата:

А если я хочу закрытый контейнер?
Занимай очередь.

MikroAcse 07.06.2013 20:38

Цитата:

А если я хочу закрытый контейнер?
Боишься своего кода? Если все правильно сделать - "закрытый контейнер" не понадобится.

Код AS3:

public class ClosedContainer extends Sprite {
    public function ClosedContainer() { super(); }
    override public function addChild(child:DisplayObject):DisplayObject { return; }
    override public function addChildAt(child:DisplayObject, index:int):DisplayObject { return; }
    override public function removeChild(child:DisplayObject):DisplayObject { return; }
    override public function removeChildAt(index:int):DisplayObject { return; }
}

А внутри класса используешь super.addChild/removeChild.

Wolsh 07.06.2013 21:15

MikroAcse, терпения не хватило переписать ВСЕ методы ДОКа? Там еще много-много вкусняшек, getChildAt(), getChildByName(), numChildren, tabChildren, mouseChildren, contains(), getChildIndex(), getObjectsUnderPoint(), setChildIndex(), swapChildren(), swapChildrenAt().
А теперь представь ту же ситуацию: некто видит что это Спрайт, пихает туда своё чадо и начинает с ним работать как ни в чем ни бывало. Компилятор молчит: вызов методов и свойств абсолютно законный. А в рантайме ошибка едет на ошибке и ошибкой погоняет.
Флэш уже пять лет живет с AS3, и все ништяк. Никто не говорит, что это ужасный баг, который похоронит технологию. Никто не говорит, что надо все бросать и вешать на каждый спрайт по менеджеру. Речь о красоте, как бы пафосно это ни звучало. О том, что Спрайт просто мегаизбыточен. У него полтора десятка публичных методов, убивающих накорню всякую инкапсуляцию. Методов, в 95% случаев не нужных вообще извне. Все они должны быть закрыты так, чтобы при необходимости вы могли создать общий доступ в наследнике. Но не открытый доступ по-умолчанию же! Вы когда класс пишете, старательно закрываете доступ ко всем его внутренностям. Приватные свойства, приватные функции. И только один-два метода сознательно(!) делаете публичными. А в это время в замке у шефа у вашего класса душа нараспашку, и любой объект извне может совершенно спокойно добавлять в него что попало и удалять его внутренние органы без разбора. Все то, на что вы сохраняли ссылки в приватных переменных, легко доступно извне в результате родовой травмы ДОК. И единственный ответ — сделай так, чтоб вся программа ломалась в рантайме, оверрайд же шь! Спасибо, конечно.
Я хочу, чтобы этих публичных свойств и методов НЕ БЫЛО вообще, в принципе. Хочу ДО, который "снаружи" не является контейнером вообще, но внутри дает полное API для работы с собственным списком отображения. Все публичные доступы я смогу написать сам. Мне это понадобится раз в полгода и займет четыре строчки, не родив ни одной ошибки.

Psycho Tiger 07.06.2013 23:14

... А зачем? :)
Что это за перестраховка от атомных взрывов? Когда я писал только на as3 я тоже болел чем-то таким.
Ошибка в рантайме при дебаге – вполне обычная ситуация. В 9 из 10 случаев эта ошибка не произойдёт если проэксклудить "лишние" с автокомплита. Сразу будет видно, что дёргать. В 1 из 10 случаев словить РТЕ – ну вот совсем не страшно. В Ruby или Python'е можно вообще приватные методы дёргать через :send. И дёргают, и живут, и код настолько красив и отDRYен, что такого в AS3 и встретить нельзя.

Красота – это прекрасно и чудесно. Только это всё таки просто код.

Final Hope 08.06.2013 01:56

Цитата:

Сообщение от Wolsh (Сообщение 1136985)
Я хочу, Хочу ДО

Wolsh, да всё-всё! Тише-тише! Уже все поняли, чего вы хотите. :) Вот: http://www.adobe.com/ru/support/contact/ Дело за малым.
Цитата:

Сообщение от Psycho Tiger (Сообщение 1136993)
Только это всё таки просто код.

Который через сто лет даже в школе читать не будут.)

Babylon 08.06.2013 02:16

Wolsh, я представляю, что мог бы написать про избыточность UI :)

Final Hope 08.06.2013 02:18

Да весь AS избыточен. В топку его. Машинный код - за ним будущее!

Tails 08.06.2013 09:24

Согласен с Wolsh, что избыточность методов чисто морально напрягает. Там ещё эвент диспетчер не всегда нужен. Но на практике это не приносит проблем, а иногда даже полезно. Вот недавно возился с minimalComps компонентами, пришлось в одном случае сверху насильно выдрать маску из компонента.

iNils 08.06.2013 20:35

Цитата:

Сообщение от Psycho Tiger (Сообщение 1136993)
... А зачем? :)
Что это за перестраховка от атомных взрывов? Когда я писал только на as3 я тоже болел чем-то таким.
Ошибка в рантайме при дебаге – вполне обычная ситуация. В 9 из 10 случаев эта ошибка не произойдёт если проэксклудить "лишние" с автокомплита. Сразу будет видно, что дёргать. В 1 из 10 случаев словить РТЕ – ну вот совсем не страшно. В Ruby или Python'е можно вообще приватные методы дёргать через :send. И дёргают, и живут, и код настолько красив и отDRYен, что такого в AS3 и встретить нельзя.

Красота – это прекрасно и чудесно. Только это всё таки просто код.

Давай все будет теперь public и без типизации? Работает и ладно.

Давай серьезно и без деградарующих примеров других языков? А то получается так: был 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
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.