Форум Flasher.ru - Организация программы

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

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

- - Организация программы (http://www.flasher.ru/forum/showthread.php?t=152059)

Организация программы

Привет всем!
А теперь к делу. Мой вопрос касается не конкретной программы, а организации всех программ в общем.

Вопрос №1
У меня есть движок, главный класс которого должен иметь доступ ко всем объектам, которые связаны с движком. Единственное, что приходит на ум - это завести массив в главном классе, а вот дальше начинаются разногласия:
1) Можно делать так:

Код AS3:

var o = new MyObject();

engine.registerObject(o);

2) Можно так:

Код AS3:

var o = new MyObject(engine);

3) Так (объявив конструкторы объектов как private):

Код AS3:

var o = engine.createMyObject();

4) И наконец, класс движка можно сделать статическим, что обеспечит доступ к его массиву из движка.
Вариант №3, к сожалению, в AS3 не проходит, т. к. AS3, такой сякой, хочет public конструктор, но мне се равно интересно, следует ли его использовать в других языках программирования.
Как вам мои варианты? Или что посоветуете?

Вопрос №2(организация взаимодействия)
У меня в программе есть несколько классов, каждого из которых ровно по 1-му экземпляру. Некоторые из классов должны взаимодействовать между собой(причём на этапе начала разработки программы я ещё точно не знаю какие). Возникают такие идеи:
1)

Код AS3:

class SomeClass

{

     public static var someClass:SomeClass;

 

     public function SomeClass()

     { someClass = this; ... }

}

2) Сделать класс статичным
Что лучше выбрать?

Вопрос №3(Вывод графики)
В большинстве языков программирования, мы обычно запускаем цикл, в котором смотрим состояние программы(игра, пауза, главное меню, и т.п.) и в зависимости от состояния рисуем то, что надо.
В AS появляется возможность разные состояния программы нарисовать в разных Спрайтах, а при очередной смене состояния, менять видимость разных спрайтов(visible = true/false;)
Это хорошо или плохо?
Хорошо ли часть графики рисовать в среде Flash'а?

Я обычно использую приблизительно такой механизм(дерево):

Код AS3:

public class Component extends EventDispatcher implements IComponent

{

  public function Component(owner:IComponent):void

  {

     registerClassAlias(Component, this);

     if (owner != null)

     {

       Component(owner).registerComponent(this);

     }

  }

  public function setOwner(owner:IComponent):void

  {

     m_owner = owner;

  }

  private function registerComponent(component:IComponent):void

  {

    components.push(component);

    component.setOwner(this);

  }

  private var m_components : Array = [];

  private var m_owner : IComponent = null;

}

 

public interface IComponent extends IEventDispatcher

{

  function setOwner(owner:IComponent):void;

}

Добавлено через 3 минуты
ну а потом можно использовать:

Код AS3:

var root:IComponent = new Component(null);

new Component(root);

new Component(root);

new Component(root);

а в конструктор компонента можно добавить ещё параметр id, в таком случае IComponent можно снабдить большинством удобных функций:

Код AS3:

public interface IComponent extends IBasicComponent

        {

                /**

                 * Добавляет новый компонент в конец очереди компонентов.

                 * @param component вставляетмый компонент

                **/

                function addComponent(component:IComponent):void;

                /**

                 * Добавляет список компонентов в конец очереди компонентов.

                 * @param components список добавляемых компонентов

                **/

                function addComponents(components:Array):void;

                /**

                 * очищает себя от всех элементов.

                 * @param clearSubComponents если true, то очищает все подкомпоненты

                 * @param finalizeComponents если true, компоненты финализируются

                */

                function clear(clearAll:Boolean = false, 

                                            finalizeComponents : Boolean = false):void;

                /**

                 * Ищет компонент по его идентификатору

                 * @param id идентификатор компонента, который нужно найти

                 * @return ссылка на компонент с указанным идентификатором

                 */

                function getComponentById(id:String):IComponent;

                /**

                 * возвращает массив компонентов, являющихся наследниками clazz.

                 * @param clazz класс, наследниками которого должны являться искомые компоненты

                 * @param index номер искомого компонента

                 * @result ссылки на компоненты-наследники clazz

                 *         null если компоненты не были найдены

                **/

                function getComponentsByPrototype(clazz:Class):Array;

                /**

                 * Вставляет новый компонент в очередь компонентов в указанном месте.

                 * @param index позиция, в которую вставляется компонент

                 * @param component компонент, который требуется вставить в очередь

                **/

                function insertComponent(index:Number, component:IComponent):void;

                /**

                 * Вставляет очередь компонент в хозяина.

                 * @param index позиция, в которую вставляются компоненты

                 * @param components массив компонентов, который требуется вставить в очередь

                **/

                function insertComponents(index:Number, components:Array):void;

                /**

                 * Удаляет компонент из списка компонентов.

                 * @param component компонент, который требуется удалить

                 * @param finalizeComponent true, еасли надо финализировать компонент

                **/

                function removeComponent(component:IComponent,

                                                                 finalizeComponent : Boolean = false):void;

                /**

                 * Удаляет указанное количество компонентов.

                 * @param startIndex индекс компонента, с которого начнеться удаление

                 * @param count количество удаляемых компонентов

                 * @param clearSubComponents

                 *        true, если нужно очистить все подкомпоненты внутри удаляемых

                 *@param finalizeComponents если true, компоненты финализируются

                 */

                function removeComponents(startIndex : Number = 0,

                                          count:Number = VisualObjectClassNameResource.MAX_COMPONENT_COUNT,

                                          removeSubComponents:Boolean = false,

                                          finalizeComponents : Boolean = false):void

Вопрос №1
Если все объекты могут использоваться только внутри движка (то есть сами по себе не имеют какого-либо смысла, будучи оторванными от него), то можно регистрировать их прямо внутри их же собственного конструктора.
Если объекты предполагают разные варианты их использования (то есть вне движка), то я бы выбрал первый вариант.

Насчет приватных конструкторов - можно объявить класс как internal и использовать фабрику, которая бы создавала нужный объект и возвращала его по интерфейсу.

Вопрос №2
Класс, у которого всегда только один экземпляр - это синглтон, если этот класс должен от кого-то наследоваться или реализовывать какой-то интерфейс, или статический класс во всех остальных случаях.

Вопрос №3
visible - не круто. Лучше использовать add/removeChild

Цитата:

Хорошо ли часть графики рисовать в среде Flash'а?

Это нормально

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

По вопросу №1:
1 - 2 - все зависит от ситуации
3 - тоже зависит от ситуации и незнаю, почему вам нужен именно приватный конструктор. Практика показала что нужно очень постараться чтобы по-ошибке вызвать не фабричный метод, а конструктор напрямую.
4 - огребете проблем

По вопросу №2
В идеале не 1 и не 2

Желательно постараться выделить иерархию зависимости классов (щас НЕ про наследование).
Т.е. постараться сделать так чтобы классы не были завязаны друг надруга, т.е. чтобы не было Класс1 общается с Классом2, класc 3 общается с классом 1, клас 2 общается с классом 3.

Как желательно делать:
- Есть главный класс 1, он рулит классами 2 и 3
Классы 2 и 3 ничего не знают о 1, зато 1 знает о 2 и 3.
- При старте в класс 1 передаются ссылки на классы 2 и 3.
Всё, никакой статики, никаких синглтонов

Синглтоны и статика используются. когда сложно протянуть общий функционал во все части приложения
Очевидный недостаток такого подхода - у Вас не получиться использовать ни один, юзающий синглтон, класс одтельно. Плюс запутывание логики

Всем спасибо за советы. Буду рассматривать.

Вопрос №4
Хорошо ли обрабатывать анимацию в enterFrame, а не в timer. В данном случае я имею ввиду достаточно простенькую анимацию, хотя вдруг есть минусы.

Цитата:

Хорошо ли обрабатывать анимацию в enterFrame, а не в timer. В данном случае я имею ввиду достаточно простенькую анимацию, хотя вдруг есть минусы.

Я знаю 3 подхода при проигрывании анимации:

1. Выставить фиксированный fps с запасом (пониже 60, обычно 30) и завязать всю анимацию на enterFrame.
Минусы: при просадке фпс движение персонажей будет замедляться, а когда есть большой запас производительности - анимация НЕ станет более плавной.

2. Выставить fps на максимум (после fp 10.1 - это 60),
а кадры переключать по таймеру с шагом, меньшим fps
Минусы: хоть завязки с fps нет - анимация может получиться более "рваной", при очень большой просадке fps анимация также будет замедляться.

3. Забыть про таймер, обновлятся по fps, но замерять время между кадрами и прокручивать анимацию пропорционально прошедшему времени
В этом случае анимация не будет замедлятся - максимум что будет - это слайд-шоу. А при запасе производительности анимация будет более плавной.
Недостатки: слегка более геморная реализация анимации.