Junik - Последние комментарии на Интерфейсы в actionscript 2.0. Часть 1. Внешние модули

В ответ на: Интерфейсы в actionscript 2.0. Часть 1. Внешние модули

Иностранец со стулом [Посетитель] — Fri, 15 Dec 2006 11:06:13 +0000

Извините, я не понимал сути интерфейса (http://flash-ripper.com/archives/000325.htm). Всё.

В ответ на: Интерфейсы в actionscript 2.0. Часть 1. Внешние модули

Иностранец со стулом [Посетитель] — Thu, 14 Dec 2006 12:30:29 +0000

Дождался новой статьи. Спасибо!

Такое чувство, что я почти понял...
Нет ли у Вас тестового fla, заценить оченно хочецца.

В ответ на: Интерфейсы в actionscript 2.0. Часть 1. Внешние модули

Fix [Посетитель] — Wed, 13 Dec 2006 12:48:14 +0000

Ага! Вот ключевая связка слов: "в главном таймлайне модуля". Тогда схема понятна

В ответ на: Интерфейсы в actionscript 2.0. Часть 1. Внешние модули

Junik [Учаснег] — Wed, 13 Dec 2006 09:15:25 +0000

Ответ для Fix

Хитрость может заключаться, например, в следующем. В главном таймлайне определяем метод getPictureSelector, который будет возвращать ссылку на нужный объект. К сожалению, полностью определить сигнатуру этого метода нельзя, то есть, вызывая этот метод у мувиклипа, нельзя быть уверенным на этапе компиляции, что вернут нужный объект. Но это можно проверить и выдать ошибку уже на этапе выполнения.

Вот пример.

Пусть у нас есть класс ConcretePicturesSelector, который имплементит интерфейс IPicturesSelector. Тогда в главном таймлайне модуля пишем примерно следующее.

var pictureSelector:IPicturesSelector = new ConcretePicturesSelector();
function getPictureSelector():IPicturesSelector {
return pictureSelector;
}

Если ConcretePicturesSelector вдруг не будет имплементить IPicturesSelector, то получим ошибку компиляции. ConcretePicturesSelector не будет включен в компиляцию главного приложения, так как его объект будут воспринимать только как нечто с интерфейсом IPicturesSelector.

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

var picturesSelector:IPicturesSelector;
if (movie.getPictureSelector() instanceof IPicturesSelector) {
picturesSelector = IPicturesSelector(movie.getPictureSelector());
} else {
trace('movie.getPictureSelector() is not instanceof IPicturesSelector!');
}

В ответ на: Интерфейсы в actionscript 2.0. Часть 1. Внешние модули

Fix [Посетитель] — Wed, 13 Dec 2006 08:45:00 +0000

Вы только не усмотрите в моих словах какой-то иронии. Мне на самом деле статья понравилась и помогла шире открыть глаза Спасибо.

В ответ на: Интерфейсы в actionscript 2.0. Часть 1. Внешние модули

Konstantin Kovalev [Учаснег] — Tue, 12 Dec 2006 18:36:16 +0000

Смысл в том, Фикс, что в некоторых случаях данный метод не исключает использование exclude-листов. И модуль, и главное приложение могут использовать одни и те же классы. В том же Юлином примере Picture - это класс, который используется и там, и там. В простых случаях (если идет получение экземпляра Picture, который, например, имеет поле url и gjkt вуыскшзешщт) можно эту мелочь игнорировать. Но если общая кодовая база все же велика, то exclude-листы все же пригодятся.

Хм. А про Preview одно из двух. Либо баг в движке, либо в теме. Проверю на досуге.

Ну а рассказать тебе про getPictureSelector оставлю Юле

В ответ на: Интерфейсы в actionscript 2.0. Часть 1. Внешние модули

Fix [Посетитель] — Tue, 12 Dec 2006 15:33:25 +0000

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

"определить в главном таймлайне метод getPictureSelector, который будет возвращать объект класса с ожидаемым интерфейсом"

Метод должен вернуть объект, предварительно создав экземпляр класса, который вынесен в отдельный модуль. Но при упоминании имени этого класса, он будет также добавлен и в главное приложение. Как быть? Или я что-то не так понял?

PS: Preview комментария не работает :/