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

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

1. Внешние модули.

В приложении есть подгружаемые модули (внешние swf файлы), от внутренней реализации которых не хочется зависеть, но и нет желания общаться с этими модулями вслепую. Плюс необходимо, чтобы классы, используемые в модуле, не участвовали в компиляции главного приложения.

Например, существует галерея картинок, которая использует модуль выбора картинок имеющихся на сервере. Этот модуль является отдельным swf файлом, в котором заключена вся необходимая ему логика. Приложению же от модуля нужны только методы showPicturesList (показать пользователю список картинок) и getSelectedPicture (вернуть выбранную пользователем картинку). Смело можно делать интерфейс IPicturesSelector с данными методами.

  1.  
  2. /**
  3. * Интерфейс для модуля выбора картинок.
  4. * @author J.Nikolaeva
  5. * @version 12.12.2006
  6. */
  7. interface IPicturesSelector {
  8.         /**
  9.          * Показ списка картинок.
  10.          * @return ничего
  11.          */
  12.         public function showPicturesList():Void;
  13.         /**
  14.          * Возвращает выбранную пользователем картинку.
  15.          * @param
  16.          * @return
  17.          */
  18.         public function getSelectedPicture():Picture;
  19. }
  20.  

Какие получаем плюсы при данном подходе?

  1. В случае неправильного обращения к модулю будет выдана ошибка на этапе компиляции, что приятно и удобно. При слепом общении с модулем можно потратить на поиск такой ошибки достаточно много времени. Конечно, стоит упомянуть об одном минусе, который существует в as2. Сама по себе подгружаемая swf не может имплементить интерфейс. Но можно пойти на разные хитрости, например, определить в главном таймлайне метод getPictureSelector, который будет возвращать объект класса с ожидаемым интерфейсом.
  2. При компиляции главного приложения классы модуля не участвуют. Они были бы включены в компиляцию при обращении к модулю, через класс объектом которого он является. Это особенно важно, когда в приложении большое количество модулей.
  3. Если необходимо будет что-то поменять в модуле или заменить весь модуль, то не будет необходимости переписывать что-то в главном приложении. Это, конечно, при условии сохранения интерфейса модуля. И более того, при изменении модуля нет необходимости перекомпилять само приложении, что является плюсом, если разработчик модуля не имеет исходников главного приложения.

Трекбек адрес этой записи

URL трекбека (щелкните правой кнопкой мыши и скопируйте ссылку)

7 комментариев

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

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

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

PS: Preview комментария не работает :/
2006-12-12 @ 18:33
Комментарий от: Konstantin Kovalev [Учаснег] Email · http://riapriority.com/blogs/constantiner.php
Смысл в том, Фикс, что в некоторых случаях данный метод не исключает использование exclude-листов. И модуль, и главное приложение могут использовать одни и те же классы. В том же Юлином примере Picture - это класс, который используется и там, и там. В простых случаях (если идет получение экземпляра Picture, который, например, имеет поле url и gjkt вуыскшзешщт) можно эту мелочь игнорировать. Но если общая кодовая база все же велика, то exclude-листы все же пригодятся.

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

Ну а рассказать тебе про getPictureSelector оставлю Юле :)
2006-12-12 @ 21:36
Комментарий от: Fix [Посетитель] Email
Вы только не усмотрите в моих словах какой-то иронии. Мне на самом деле статья понравилась и помогла шире открыть глаза :) Спасибо.
2006-12-13 @ 11:45
Ответ для 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!');
}
2006-12-13 @ 12:15
Комментарий от: Fix [Посетитель] Email
Ага! Вот ключевая связка слов: "в главном таймлайне модуля". Тогда схема понятна :)
2006-12-13 @ 15:48
Комментарий от: Иностранец со стулом [Посетитель] Email · http://www.damon.ru/
Дождался новой статьи. Спасибо!

Такое чувство, что я почти понял... :)
Нет ли у Вас тестового fla, заценить оченно хочецца.
2006-12-14 @ 15:30
Комментарий от: Иностранец со стулом [Посетитель] Email · http://www.damon.ru/
Извините, я не понимал сути интерфейса (http://flash-ripper.com/archives/000325.htm). Всё.
2006-12-15 @ 14:06

Оставить комментарий


Ваш email адрес. (Не будет показан на сайте.)

Ваш URL будет показан.
:!: :?: :idea: :) :D :p B) ;) :> :roll: :oops: :| :-/ :( :'( |-| :>> :yes: ;D :P :)) 88| :. :no: XX( :lalala: :crazy: >:XX
(Заменить прерывания строк на <br />)
(Имя, email и сайт)
(Разрешить пользователям посылать вам сообщения (ваш email не отображается).)
3 + 2 + 7 - 1?
antispam test

Вы можете использовать OpenID чтобы предоставить ваше имя, email и url.