|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Flash Aксакал
Регистрация: Jun 2005
Сообщений: 636
|
[as2] interface'ы - давайте раставим все точки на и
предистория:
была такая тема - собственно интересует только часть про интерфейсы? профи объясните пожалуйста тогда такое: interFace.as classA.as test.fla код декомпиллера: // [Action in Frame 1] a = new classA(); // Action script... // [Initial MovieClip Action of sprite 1] #initclip class interFace { function interFace() { } // End of the function } // End of Class #endinitclip // Action script... // [Initial MovieClip Action of sprite 2] #initclip class classA implements interFace { function classA() { } // End of the function function myTest(Void) { } // End of the function } // End of Class #endinitclip и при просмотре клипа деббагером в глобале есть функция interFace |
|
|||||
Flash Aксакал
Регистрация: Jun 2005
Сообщений: 636
|
вообщем кому интересно:
ответ Nox Noctis: Цитата:
|
|
|||||
МЕГАФЛЭШЕР
Регистрация: May 1999
Адрес: Россия, Москва
Сообщений: 1,181
|
думаю изначально нужно забыть про анализ AS2 через декомпиляцию
при компиляции AS2 переводится в более простые конструкции (аля AS1), а программа декомпилятор на основе стандартного "строения" AS1 кода полученного при компиляции из AS2, создает некое свое "предположение" - как возможно, выглядел код до компиляции в AS2. По интерфейсам. И в AS2 и в других языках, интерфейс лишь средство ООП, то есть упорядочивание структуры классов, а так же (если хорошее IDE) средство автоматизации работы программиста. Создал интерфес - редактор может автоматически создать реализацию этого интерфеса или же при добавлении implements в существующий класс - автоматическое создание методов, реализующих данный интерфес(ы). к тому же, есть значительно отличие между использованием интерфейсов в AS2 и других языков (далее, как пример, java). В AS2 - динамическая типизация, в java - жесткая типизация - компилятор не позволит обмануть его, подставив другой класс, не обладающим нужным типом, вызов несуществующего метода, приведет к исключетельной ситуации. К тому же, если "обмануть" компилятор - компилить "правильно", а использвать не правильно, то в момент выполнении программы будет так исключетельная ситуация. В AS2 - принципы ООП есть лишь декларация, "хороший тон" программирования, после компиляции и проверок, программист може на все это дело "забить". И тем более глупо рыться в коде сгенеренном декомпилятором. И самое искусственное в AS2 с точки зрения "обязательности" - это интерфейсы. В java интерфейсы позволяют обойти множество ограничений, одиночного (не множественного) наследования - класс може относиться к нескольким "группам по интерфейсам" и можно ожидать от класса необходимого поведения. К тому же интерфейс можно указывать как тип, и в контексте конкретного класса и его реализации, не нужно будет знать о том, что некий объект, кроме того что он реализует некий интерфейс, обладает еще каким то другим функционалом. Итак, интерфесы в AS2 - 1. хороший тон программирования. Организация классов в виде стандартных структур, с ожидаемым поведением. 2. средство автоматизации (пока не поддерживается не одним IDE, но скоро появятся). Во первых новый ASDT вероятно будет это уметь, во вторых точно уже умеет FDT. 3. Применение стандартных паттернов проектирования основанных на интерфесах. 4. Средство создания Plug-and-play фреймвороков. остановлюсь на последнем пункте, например, есть некий класс. Например мувиклип. Загружается swf библиотека, которая регистрирует для данного класса некий функционал. Мувиклип реализует стандартный интерфейс, который определяет возможность узнать, есть ли утилита этого класса, которая может работать по нужному интерфейсу. Если такая имеется, то запрашивается экземпляр класса реализующий нужный интерфейс, и производится работа не с конкретным мувиклипом, а с данной утилитой. Здесь используется два принципа - работа с интерфейсами, и принцип композиции. Таким образом можно подменять реализацию стандартных действий с классами, и группировать их по функционалу - как бы предполагать что они будут, но в момент написания конкретной реализации "начихать" на то что они пока не существуют в природе. плюс, упрощение реализации, вместо того, чтобы реализовывать с десяток интерфейсов в одном классе, создается десять классов реализующих данные интерфейсы. и еще о декомпиляции. Интерфейсы для того превращаются в некие пустые классы, чтобы их зарегистрировать в классе реализующие их, и потом определить с помощью instanceof, что класс экземпляр нужного типа. |
Часовой пояс GMT +4, время: 13:19. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|