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

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

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. Если необходимо будет что-то поменять в модуле или заменить весь модуль, то не будет необходимости переписывать что-то в главном приложении. Это, конечно, при условии сохранения интерфейса модуля. И более того, при изменении модуля нет необходимости перекомпилять само приложении, что является плюсом, если разработчик модуля не имеет исходников главного приложения.
7 комментариев Отправить трекбек

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

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
Комментарий от: Junik [Учаснег] Email · http://riapriority.com/blogs/junik.php
Ответ для 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.