интерфейсы

[nauroman]

Делаю карточную игру.
Хочется всё это сделать модульно, чтобы получилось,что-то вроде нескольких dll. т.е. card.swf, cards.swf, scene.swf, cardsGame.swf group.swf и т.п.

Думаю, что нужно сделать классы с описание интерфейсов. Типа того

Card.as

package
{
	public class Card implements ICard
	{
		private var _data:Object;
		
		public function set data(param_data:Object)
		{
			_data = param_data;
		}
	}
}

ICard.as

package
{	
	public interface ICard
	{
		function set data(param_data:Object);
	}
}

Теперь мне как-то нужно скомпилировать Card.swf

Я делаю это в FB3 (установил только сегодня, специально для этого. Как в flash cs3 делать swf без fla я не знаю)

Но мне нужно, как-то создавать экземпляры класса Card, используя Card.swf . Т.е. что-то вроде этого:

Cards.as

package
{
	public class Cards
	{
		private var _cards_ar:Array;
		
		public function Cards()
		{
			var loader:Loader = new Loader();
			loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loadCompleteHandler);
			loader.load(new URLRequest('Card.swf'));
		}
		
		private function loadCompleteHandler(e:Event):void
		{
			var info:LoaderInfo = e.target as LoaderInfo;
			var module = info.content as ICard;
 
                        // у меня есть module но я не могу создавать экземпляры типа Cards, т.к. не могу прописать в ICards конструктор function Cards();
		}

		public function addCard(param_card:ICard) // ???
                {
                        var card:ICard = new Card(); // ???
		}
	}
}

Вообще какое должно быть архитектурное решение ?

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

Тут же по пути встаёт вопрос с ресурсами, из которых будет собираться карта (картинки)

[etc]

getDefinition

[wvxvw]

А класс Card в проекте не нужен до компиляции? Т.е. зачем его загружать?
http://www.onflex.org/ted/2007/08/us...h-cs3-code.php
Пошаговое описание как создать проект в ФБ.

[nauroman]

1. При чём тут getDifinition ? т.е. это, конечно, крутой метод и всё такое... но...
2. В общем, суть такая. Мне нужен swf, который содержит какой-то класс (и, желательно, мувики), из которого я могу потом наделать объектов. Т.е. есть Card.swf. В нём лежит класс Card. Я его загружаю в другой swf и делаю потом что-то вроде var card:Card = new Card();

[etc]

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

1. При чём тут getDifinition ? т.е. это, конечно, крутой метод и всё такое... но...
2. В общем, суть такая. Мне нужен swf, который содержит какой-то класс (и, желательно, мувики), из которого я могу потом наделать объектов. Т.е. есть Card.swf. В нём лежит класс Card. Я его загружаю в другой swf и делаю потом что-то вроде var card:Card = new Card();

getDefinition и есть ответ на ваш второй пункт.

[nauroman]

а если не тяжело, можно пару строчек с примером, начиная от

var info:LoaderInfo = e.target as LoaderInfo;

[etc]

А вы не можете в справке посмотреть?

[nauroman]

Посмотрел. Спасибо. Тогда такой вопрос - как скомпилировать просто card.as ? В справке написано:

А как скомпилировать в flash cs3 ?

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

Есть другой способ скомпилировать swf так, чтобы я потом мог создавать экземпляры класса из этой самой swf ? Что, если написать в первом кадре компилируемой swf

import cards.Card

var card:Card;

Это, скомпилирует мне нужную swf, без extends MovieClip, но как потом добраться до Card ?

[Iv]

Есть два принципиально разных варианта решения:
1. в первом случае подгрузка классов происходит на лету. Ты делаешь проект, состоящий из разных swf файлов и главным файлом всасываешь необходимые swf.
В этом случае также имеется две стратегии: методом эксклудов и методом, обозначенным выше Денисом getDefinition+интерфейсы.

2. во втором случае сборка производится во время компиляции из разных swc файлов, разработка над каждым из которых идет независимо от проекта.

Способы с применением экслудов и интерфейсов не исключают возможности применения swc.

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

Способ с getDefinition позволяет установить двунаправленную связь, но куда более трудоемок (и как по мне, весьма коряв).

Ну и в довершение напомню, что все эти способы можно применять совместно.

Сейчас пропишу когда и что лучше применять.

[Iv]

Начну с SWC библиотек
Это очень и очень мощный инструмент. Представляют собой скомпилированные библиотеки, которые могут быть подключены в любой проект.
Отсюда и подход: универсальные классы и даже целые пакеты классов и проекты можно однажды упаковать и включать в любые проекты.
Эти библиотеки удобно распространять, особенно, если не очень хочется показывать исходный код (хотя защита весьма условна).
SWC файлы представляют собой ZIP-нутый набор файлов включающий в себя XML описание, SWF файл, иконку. Чтобы заглянуть внутрь SWC файла достаточно изменить его расширение на ZIP и открыть.
Если поместить SWC файл в папку:
C:\Documents and Settings\{user}\Local Settings\Application Data\Adobe\Flash CS3\en\Configuration, то он будет доступен в панели Components во Flasah IDE.
Чтобы использовать их в FDT или Flex, их нужно соответствующим образом прилинковать в проект.

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

==================================
Далее принципиально возможны три случая:
1. родительский ролик нуждается в классах дочернего и дочерний нуждается в классах родительского.
В этом случае скорее всего следует объединить в один. Если это нежелательно, то попытаться выделить единый родительский для этих роликов и установить связь родитель - дети или родитель - ребенок - ребенок. И строить дальше отношения на стратегии эксклудов.

2. родительский ролик нуждается в классах дочернего.
В этом случае желательно включить дочерний в родительский, может быть как SWC библиотеку.

3. дочерние ролики нуждаются в классах родителя.
Это явный кандидат на стратегию эксклудов.

4. родитель и дети самостоятельны и независимы и лишь обмениваются друг с другом ограниченным набором команд.
Стратегия применения интерфейсов в купе с getDefinition как раз для этого случая.
==================================


--== getDefinition + интерфейсы ==--
Главный ролик грузит в себя другой вполне себе независимый ролик и контактирует с ним ограниченным набором команд.
На примере это выглядит так: например, на запрос пользователя нужно загрузить модуль "погода", немного с ним повзаимодействовать и выгрузить. Это наш случай. Определяем интерфейс общения и поехали.

Этот способ неудобен в применении, если главному или дочернему ролику требуется обширное знание потрошков оппонента. В таких случаях нужно менять архитектуру.


--== стратегия эксклудов ==--
Очень хорошо подходит для случаев, когда родительский ролик подгружает заведомо неизвестное количество дочерних роликов.

----------- допишу попозже -----------------