Форум Flasher.ru - Исчерпывающий смысл Extends

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Исчерпывающий смысл Extends (http://www.flasher.ru/forum/showthread.php?t=202386)

Цитата:

А на флэш девелопе воркфлоу лучше? Может тогда сразу на нём всё делать, не парицца с CS.

Может хватит уже смешивать разные вещи?
Flash CS (уже CC) - инструмент для создания анимации, моделек, изображений векторных.
FlashDevelop - инструмент для написания кода и не более.

Лично я строю базовый класс на основе Sprite, а дальше дело вкуса

воркфлоу - workflow - дословный перевод технологический процесс.
Так вот вопрос чем же отличается воркфлоу СS , FD и FB в следующем коде?

Код AS3:

package  

{

        import flash.display.Sprite

        public class Main extends Sprite

        {

 

                public function Main() 

                {

                        trace("Тест воркфлоу");

                }

        }

}

Что имелось в виду: Flash CS предлагает код писать привязывая его к графическим объектам, даже если это не нужно. Так происходит потому, что в редактор заложены возможности генерации соответствующих классов из шаблонов. Подключение библиотек компонентов так же требует наличия графических элементов и т.д. Это и приводит к тому, что часто без необходимости, люди которые используют / выросли на этом редакторе создают классы наследуя их от Sprite / MovieClip.

Это не типично для, например, FlashDevelop или FlexBuilder где, в первом, обычно пишут обычные AS3 классы, наследуя их по необходимости от того, от чего нужно. В билдере, например, есть другая замашка - все складывать в тег <s:Application/> - просто потому, что так сделать удобнее / быстрее.

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

В этом случае, самый простой вариант - вам придется передавать в ваш класс ссылку на stage или на любой другой DisplayObjectContainer, на который вы будете вешать вашу самостоятельную графику

В общем я сторонник точки зрения товарища Babylon: если класс будет содержать графику - наследуем Sprite.

Да я тоже сторонник его точки зрения и более того Adobe тоже сторонник его точки зрения.
но как понимать ?

Цитата:

Так что я бы советовал оставить Sprite / MovieClip в покое - не наследовать их / не пытаться изменить поведение по умолчанию, а просто включать их как члены ваших классов. Т.е. композиция вместо наследования.

Как говорилось в одной статейке:

Цитата:

I OOP the hell out of everything

Я так понял этот подход нужен для того, чтобы не пытаться придумывать свое поведение Спрайта или Мувика, а просто использовать их для хранения графики)

Просто тут проблема в том, что в любом случае придется добавлять эти объекты, которые являются "членами ваших классов" на stage, пусть даже через посреднические DisplayObjectContainers, а это уже разработка на уровне реализации, которую ой как не любят сторонники труЪ-ООП

То есть это придумывание своего велосипеда?Если же нет , дайте ссылку где Adobe , предлагает все это, как решение каких либо задач.Почитаю ,очень интересная структура получается.

Попробую объяснить мысль.

Вариант с наследованием:

Код AS3:

class Person extends Sprite {

    public var name: String;

    public var avatar: Sprite;

 

    public function Person(name: String, avatar: Sprite) {

        super();

        this.avatar = super.addChild(avatar);

        var signature: TextField = new TextField();

        signature.text = this.name = name;

        super.addChild(signature);

    }

}

Вариант без наследования:

Код AS3:

class Person {

    public var name: String;

    public var avatar: Sprite;

 

    private var canvas: DisplayObjectContainer;

 

    public function Person(canvas: DisplayObjectContainer,

                           name: String, avatar: Sprite) {

        super();

        this.canvas = canvas;

        this.avatar = canvas.addChild(avatar);

        var signature: TextField = new TextField();

        signature.text = this.name = name;

        canvas.addChild(signature);

    }

}

Почему с моей точки зрения второй вариант лучше:
1. Не возникает когнитивного диссонанса от того что человек является разновидностью спрайтов (на ум приходят феи и напитки).
2. Второй класс просто гораздо меньше по размеру. Редактируя этот класс вы не будете страдать от избытка методов и свойств в автодополнении.
3. Вы не унаследовали ничего такого, что помешало бы вам работать с классом человека, как с человеком. Например, человек может быть в маске (на аватарке), но слот mask уже занят в классе Sprite под абсолютно другие цели.