ООП и архитектура простой игры

[undefined]

dimarik,предложи свой вариант этого кода:

var cl:*= getDefinitionByName(linkage_id);
if (cl is Class) {
	view = new cl() as DisplayObject;
	addChild(view);
}

Самое страшное что тут может быть - в cl запишется null.Тогда компоненту просто не выставится вьюха, что будет сразу заметно.На крайняк можно кидать эксепшен с описанием.

Добавлено через 6 минут

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

Как же мне тогда узнать нажали мыша или кнопку на клаве без проверки типа?

[dimarik]

Что же самое страшное в твоем примере? Например, у меня есть MyObject extednds DisplayObject (на самом деле extends DisplayObject нельзя, можно от других наследников DisplayObject). А вот в нем объявлен метод, например, moveTo(x, y). Такого метода, конечно, нет у DisplayObject и конструкция типа

view = new cl() as DisplayObject;
view.moveTo(0, 0);

Вызовет при компиляции справедливый Error: нет такого метода у объекта с типом DisplayObject.
Что же, нам придется либо кастовать view к MyObject с проверкой результата приведения на null, либо... сама суть такого инстанцирования неправильна.

Твой пример показывает скорее всего то, как еще можно сделать, в обход проверки типизации в compile time. Такие случаи бывают, да. Например, ну, никак нельзя допустить вкомпиливания кода со всеми зависимостями в прелоадер. Тогда мы можем так поступить. И это осознанный шаг.

[undefined]

ну так на то оно и view - голое визуальное представление, стандартного DisplayObject вполне достаточно.

Добавлено через 2 минуты
Вообще эта конструкция для простого связывания графики из библиотеки с пользовательскими классами.Для новичка большего и не нужно имхо.

[dimarik]

Сообщение от undefined

Как же мне тогда узнать нажали мыша или кнопку на клаве без проверки типа?

Я привел пример проверки event is <ConcreteEvent>. Но лучше сделать каждому событию свой обработчик. Либо, если неважен подтип события, сделать его общим

this.addEventListener(IOErrorEvent.IO_ERROR, this.handler_error);
this.addEventListener(SecurityErrorEvent.SECURITY_ERROR, this.handler_error);
 
private function handler_error(event:ErrorEvent):void {
    trace(this, "handler_error", event);
}

Добавлено через 3 минуты

Сообщение от undefined

ну так на то оно и view - голое визуальное представление, стандартного DisplayObject вполне достаточно.
Вообще эта конструкция для простого связывания графики из библиотеки с пользовательскими классами.Для новичка большего и не нужно имхо.

Вы всегда только на картинку смотрите? Управлять ею не будете? Неужели у символа из библиотеки в роду только DisplayObject?
А вот если к символу более сложный чем MоvieClip, класс привязан? Как вы будете управлять экземпляром?
То-то же )

[undefined]

Я привел пример проверки event is <ConcreteEvent>

Ну значит проверка типа в рантайме допустима.Ок.

Но лучше сделать каждому событию свой обработчик.

В большинстве случаев 90% кода обработчиков будут совпадать, отличие, например, в моем случае только в том, что пишется в лог.Получается будем иметь два одинаковых метода отличающихся одной строкой.Уж лучше я лишний иф напишу.

Добавлено через 9 минут

Вы всегда только на картинку смотрите? Управлять ею не будете? Неужели у символа из библиотеки в роду только DisplayObject?
А вот если к символу более сложный чем MоvieClip, класс привязан? Как вы будете управлять экземпляром?
То-то же )

Как раз для этого и вводится иерархия с GameObjectBase в корне.Хочется чего-то большего чем есть в DisplayObject?Вперед, наследуемся от GameObjectBase и дописываем свой функционал.

[dimarik]

Пишите, шура, пишите. Я вам не нужен )

[Wolsh]

Вообще, эта тема с

var cl:*= getDefinitionByName(linkage_id);

она же для того, чтобы вычитать в XML название класса для создания какой-нибудь финтифлюшки. И понятно, что тут зарыта куча подводных камней, как всегда бывает при String-typed вместо Strong-typed. Опечатки, кодировки, заглавные/прописные, дефисы/подчеркивания и просто невнимательность, в результате которой объявленного в XML класса не оказывается в скомпилированной библиотеке. Эти проблемы практически нерешаемы со 100% гарантией (хотя от всех каллиграфических проблем можно избавиться, используя числовые id вместо названий классов, а названия сопоставить id во "внутреннем" реестре классов). Но вот избавиться от String-typed не так уж сложно обычным свитчем, где по значению строки linkage_id выдается ссылка на настоящий, 100% вкомпилированный Класс.
Ну, типа

var className:String = linkage_id.toUppercase();
switch (className)
{
	case "CIRCLE" : _view = new Circle(); break;
	case "RECTANGLE" : _view = new Rectangle(); break;
	case "TRIANGLE" : _view = new Triangle(); break;
	case "ELLIPSE" : _view = new Ellipse(); break;
	default : _view = new LostPicSample();
}

[in4core]

undefined ваша структура

var cl:*= getDefinitionByName(linkage_id);
if (cl is Class) {
	view = new cl() as DisplayObject;
	addChild(view);
}

от плохой реализации. Приведите мне четкий пример, когда вообще мне нужно использовать getDefinitionByName ?

[caseyryan]

Сообщение от in4core

Приведите мне четкий пример, когда вообще мне нужно использовать getDefinitionByName ?

Я могу привести пример.
Делаешь ты, к примеру, игру. В редакторе локаций добавляешь персонажей или объекты, которые в игре представлены определенными классами. Сама локация сохраняется в XML или в JSON, со строчным представлением всех классов персонажей и объектов и их настройками. Чтобы потом этих персонажей в игре воссоздать в нужном месте, как раз и используется getDefinitionByName().

Можно конечно их пронумеровать в игре, или приписать им какое-то название, по которому их находить. Но чем эта реализация лучше?

[Wolsh]

Но чем эта реализация лучше?

а ведь я специально использовал геометрические фигуры, ради синенького слова Rectangle. Ни на что не намекает?