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

[nns2009]

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

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

var o = new MyObject();
engine.registerObject(o);

2) Можно так:

var o = new MyObject(engine);

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

var o = engine.createMyObject();

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


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

class SomeClass
{
     public static var someClass:SomeClass;
 
     public function SomeClass()
     { someClass = this; ... }
}

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


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

[tofflife]

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

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 минуты
ну а потом можно использовать:

var root:IComponent = new Component(null);
new Component(root);
new Component(root);
new Component(root);

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

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

[gloomyBrain]

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

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

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

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

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

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

[tofflife]

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

[expl]

По вопросу №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.
Всё, никакой статики, никаких синглтонов

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

[nns2009]

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

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

[expl]

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

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

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

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

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