Форум Flasher.ru
Страница 2 из 3 < 1 2 3 >
Показывать 40 сообщений этой темы на одной странице

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   Помогите разобрать понятие интерфейса (http://www.flasher.ru/forum/showthread.php?t=157498)

AlexCooper 12.09.2013 16:53
Цитата:
Сообщение от razerw (Сообщение 1146015)
что тогда будет в таком случае.
я отправляю в метод blow() интерфейса IBlowable аргумент.
Но метод blow() имплементирова в классах Car, Tank. какая будет реакция? аргумент придет в оба класса? Car, Tank?
Нет. Интерфейс, это как инструкция для пользования. То-есть класс который "хочет" реализовывать интерфейс, 100% должен содержать описанные свойства и методы интерфейса который он реализовует.

Аналогию можно провести к USB-порту. К примеру вы берёте объект "мышка", проверяете есть ли у него интерфейс "USB", если есть, значит Вы можете его подключить к USB на Вашем компьютере и начать ею пользоваться. Но это не значит что если вы подключили мишку и начали использовать USB порт, то все устройства с USB начнут работать.
И соответсвенно существует огромное количество девайсов с "USB-интерфейсом", флешка, блютуз, клавиатура, колонки, мышка и так далее которые используют USB-интерфейс по своим нуждам. Что-бы подключить какой-либо из устройств, нам нужно узнать, реализовывает ли объект USB-интерфейс и если реализовывает использовать его по своим нуждам ( соответсвено передвигая мышкой мы будем передавать данные через сам интерфейс, а с другой стороны эти данные будут считываться ). То-есть прямоугольный штекер с четырьмя контактами по которым передаются различные данные. Что в программирование реализовывалось бы, как различные методы по работе данного интерфейса.

KumoKairo 12.09.2013 17:04
Цитата:
я отправляю в метод blow() интерфейса IBlowable аргумент.
Ошибка компиляции, метод blow не имеет входных параметров

AlexCooper 12.09.2013 17:07
Как пример допустим у нас есть два класса ( пишу не для компилятора )
Код AS3:
class DigitalClock implements IClock {

    public function showTime(time:Date):void {

        // и тут выводим время в цифровом формате, то-есть 10:23:33

    }

}
Код AS3:
class MechanicsClock implements IClock {

    public function showTime(time:Date):void {

        // тут рисуем стрелочки и выводим время как на механических часах

    }

}
и соответсвено сам интерфейс, который говорит о том что это - часы, а значит классы которые будут его реализовывать, должны показывать время ( пример: при вызове метода showTime )
Код AS3:
public interface IClock {

    function showTime(time:Date):void

}
теперь где-то в программе мы пишем

Код AS3:
 

var mClock:MechanicsClock = new MechanicsClock();

var dClock:DigitalClock  = new DigitalClock();

 

if (mClock is IClock) showClock(mClock);

if (dClock is IClock) showClock(dClock);

 

function showClock(clock:IClock):void {

    clock.showTime(new Date());

    addChild(clock);

}

razerw 13.09.2013 10:14
Цитата:
Сообщение от AlexCooper (Сообщение 1146040)
Как пример допустим у нас есть два класса ( пишу не для компилятора )
Код AS3:
class DigitalClock implements IClock {

    public function showTime(time:Date):void {

        // и тут выводим время в цифровом формате, то-есть 10:23:33

    }

}
Код AS3:
class MechanicsClock implements IClock {

    public function showTime(time:Date):void {

        // тут рисуем стрелочки и выводим время как на механических часах

    }

}
и соответсвено сам интерфейс, который говорит о том что это - часы, а значит классы которые будут его реализовывать, должны показывать время ( пример: при вызове метода showTime )
Код AS3:
public interface IClock {

    function showTime(time:Date):void

}
теперь где-то в программе мы пишем

Код AS3:
 

var mClock:MechanicsClock = new MechanicsClock();

var dClock:DigitalClock  = new DigitalClock();

 

if (mClock is IClock) showClock(mClock);

if (dClock is IClock) showClock(dClock);

 

function showClock(clock:IClock):void {

    clock.showTime(new Date());

    addChild(clock);

}
спасибо отличный пример

KumoKairo 13.09.2013 10:38
Код AS3:
addChild(clock);
Кстати тоже работать не будет, выдаст ошибку что не может добавить в дисплей лист объект, не наследующий DisplayObject. Как выход кастануть к дисплей объекту
Код AS3:
addChild(clock as DisplayObject);
Но тогда есть вероятность получить null reference exception, да и вообще весь полиморфизм коту под хвост (может наш IClock выводит информацию о времени в консоль, и вообще не является DisplayObject, а мы его пытаемся в дисплейлист добавить?)
Код AS3:
if(clock is DisplayObject)

{

    addChild(clock);

}
Вот так конечно можно перестраховаться, но это совсем не красиво

Wolsh 13.09.2013 11:11
1. Почему "не красиво"?
2. А как "красиво"?
3. Вообще, использовать интерфейсы для наследников ДО немного не тру ООП, поэтому и заморачиваться не стоит. В том смысле, что вообще-то не совсем нормально, когда всякие методы хранит и реализует Спрайт. Предполагается, что ДО это только отображение, картинка Сущности, а сама Сущность это "Модель Сущности", и всякие хитрые методы — у нее. В простых проектах, конечно, так не заморачиваются. Но в них и интерфейсы не шибко то применяют))

KumoKairo 13.09.2013 11:20
1. Потому что объект, в конце концов, должен сам решать, как он будет отображать свою информацию (разумеется мы сначала ведем переговоры и делаем так, чтобы накладок с отображением не возникало: если нашим часам нужен контейнер для отображения себя - предоставим, но это уже конкретная реализация конкретного класса)
2. Добавлять этот объект на экран там, где мы точно знаем, что это DisplayObject, и его точно можно добавить на сцену, только и всего :)
На примере кода товарища AlexCooper, добавлять на экран сами объекты mClock и dClock (там они все равно добавляются одновременно)
Или определить передачу контейнера в класс, в который (в контейнер), конкретные часы будут добавлять нужные вещи
3. Приму к сведению, спасибо)

Wolsh 13.09.2013 11:52
1. Ну так он сам и решает, как отображать свою информацию. Вы решаете только, отображать ли этот объект)))
2. Ну так вы и проверяете, точно ли это ДО))) А как иначе, если метод принял объект в переменную типа Интерфейс? Делайте наоборот)) принимайте как ДО и проверяйте на интерфейс перед вызовом методов интерфейса. Просто мне непонятно, где страдает "красота". Точно так же Вы можете принимать объект как ДО, но вам придется делать такую же проверку, если захочется использовать методы Текстфилда или МувиКлипа. Чтобы "точно знать" надо отказаться от полиморфизма во всех его проявлениях ;)

AlexCooper 13.09.2013 12:10
KumoKairo я же сделал пометку что пишу не для компилятора.
Суть вовсе не в DisplayObject и addChild. Реализаций можно придумать немереное количество.
Естественно чтоб всё работало классы MechanicsClock и DigitalClock должны прежде всего наследоваться от DisplayObject или классов его наследников. А потом только уже пихать в addChild.
Давайте не будем отходить от темы "Помогите разобрать понятие интерфейса" к теме "Как не словить ошибку при addChild"

Добавлено через 4 минуты
поддерживаю мнение Wolsh.

Akopalipsis 24.10.2013 14:46
Не стал создавать тему из-за неоднозначности своего вопроса.
Дело вот в чём - после прочтения книг, в моем сознании отпечаталось, что при реализации интерфейса не обязательно соблюдать строгий порядок , как при переопределении. То есть, можно добавлять новые параметры. Вчера я открыл книгу с целью подтверждения своих слов и не обнаружил там не чего похожего.
Если я путаю и так нельзя, то с чем я путаю?)

samana 24.10.2013 14:57
Цитата:
Сообщение от Akopalipsis (Сообщение 1149682)
Что при реализации интерфейса не обязательно соблюдать строгий порядок , как при переопределении. То есть, можно добавлять новые параметры.
Простите, не могу понять ваш вопрос. О каких порядках и параметрах идёт речь?

Akopalipsis 24.10.2013 15:09
В интерфейсе
Код AS3:
function test(param:int):void
а в имплементирующем классе
Код AS3:
public function test(param:int, string:String):void

{

        //

}
То есть, можно ещё параметров добавить.

Wolsh 24.10.2013 15:11
Нет. Это называется "перегрузка метода". В AS3 не поддерживается.

Akopalipsis 24.10.2013 15:30
Спасибо! Очень удивлён, так как твердо был убеждён, что читал именно про возможность несоблюдения параметров.

in4core 24.10.2013 16:10
Wolsh - по сути перегрузка это

function a(c:String) {}
function a(d:int) {}
Например. Но ее тут нет - да

А тут приведена вообще другая конструкция интерфейс одно, класс другое. Так вообще нельзя

Fogflasher 24.10.2013 16:21
Читал главу из Мука некоторое время назад.
По отдельности вроде бы все было понятно, но в целом, как-то картинка удовлетворяюещго понимания не сформировалась.

Вот сейчас этот трэд бегло прочитал, и сложилось такое впечатление:

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

Как бы шутка конешно, но на уровне нуба, оно как-то так и воспринимается.

Akopalipsis 24.10.2013 16:24
Fogflasher Везёт Вам! я долго не мог понять для чего они нужны.

Fogflasher 24.10.2013 16:56
Akopalipsis, я и сейчас полностью не понимаю, поэтому пока не касался этого вопроса на практике.

Wolsh 24.10.2013 16:58
На самом деле никакое "наследовательское" ограничение Вы не обойдете. Если какой-нибудь наследник Спрайта и наследник EventDispatchera реализуют один интерфейс, добавить в СписокОтображения Вы все-равно сможете только первого, но второго никак. Так что никакого шарлатанства не получится, игра по-честному: интерфейс не подменяет Тип Данных, он ЯВЛЯЕТСЯ другим уникальным типом данных, и ничего сверх заявленного не обещает. Он не даст Вам выдать Шейп за ТекстФилд.

Tails 24.10.2013 17:19
Не надо пытаться понять нубу, что такое интерфейс. Вы его поймёте, когда он вам понадобится. Оставьте эту главу на потом и продолжайте дальше учить.

Интерфейс - это тип данных. Такой же как класс, только абстрактный. Всё остальное растёт из этого.

Dukobpa3 24.10.2013 18:15
Интерфейс это как описание стандарта.
То что в производстве называется ГОСТ-ом. Т.е. описание требований к некоторому продукту. Но сам по себе ГОСТ бесполезен. Это просто свод правил поведения.

Точно так же и интерфейс. Если мы видим класс который имплементит интерфейс - значит можем быть уверенны что он соответствует этому стандарту.
Соответственно можем к нему обращаться по указанным именам переменных или функций.

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

Babylon 24.10.2013 19:03
Допустим, Вы сделали игру и Вы хотите, чтобы кто-то еще сделал для нее разные сущности - предметы, оружие, врагов. Для совместимости Ваших и сторонних классов и придуман интерфейс. Если сторонний класс не имеет нужных Вам интерфейсов (их может быть несколько) Вы, используя фабрику, наделяете его нужным интерфейсом. Исходный класс остается таким каким и был. Новый класс как бы проксирует его.

Добавлено через 1 минуту
Также интерфейсы используются для унификации API

Котяра 28.10.2013 14:24
Цитата:
Также интерфейсы используются для унификации API
Масло масляное.
API - Application Public Interface

Psycho Tiger 28.10.2013 15:04
В контексте масла этот кусок меня куда больше смущает :)
Цитата:
Допустим, Вы сделали игру и Вы хотите, чтобы кто-то еще сделал для нее разные сущности - предметы, оружие, врагов. Для совместимости Ваших и сторонних классов и придуман интерфейс.
Вот получили мы с тобой интерфейс IWeapon, будем строгать для игры пушки. Реализовали, сделали. Я унаследовал свою пушку от Sprite, а ты от XML. Чья пушка вызовет эксепшн при добавлении в дисплай лист?
Значит, для примера куда больше подходит псевдоабстрактный класс, унаследованный от DO.
Цитата:
Если сторонний класс не имеет нужных Вам интерфейсов (их может быть несколько) Вы, используя фабрику, наделяете его нужным интерфейсом.
Метопрограммирование – это чудесно, но, к сожалению, в языке оно развито так же плохо, как и лямбды.
Фабрика – как-бы-паттерн который создаёт экземпляры в рантайме. Поделись опытом, как в рантайме наделять классами. Действительно ли оно стоит? Возможно, эффективней будет всё-таки выкинуть фабрику да писать классы в редакторе, по старинке, складывая головную боль на компилятор?
Цитата:
Новый класс как бы проксирует его.
Почему как-бы? Это и есть прокси. Причем в самом настоящем его оверхеде. Вместо реплики "а класс-то неизменен!" лучше изменить исходный класс – вот где ниндзюцу.
(да, не всегда есть доступ к исходным кодам других классов, но... Станиславский не поверит.)

Dukobpa3 28.10.2013 15:14
Цитата:
Сообщение от Psycho Tiger
Я унаследовал свою пушку от Sprite, а ты от XML.
Вот здесь я в кои-то веки на сторону бабулона стану.
Это уже не косяк подхода, это косяк флеша, что он не имеет никаких интерфейсов для дисплей-листа, окромя IBitmapDrawable. Который, собственно, никуда не упирается абсолютно.
Несколько проектов подряд последних были модульные, и именно с такой постановкой задачи как озвучил бабулон. Часть модулей писали мы, часть аустсорсили.
Благо что каждый модуль это флешка, потому он просто физически не может быть ничем кроме спрайта. А если бы они колбасили нам допустим одну библиотеку в которой пачка классов-модулей - была бы *опа.

Но опять же повторюсь - это адобовцы косоруко проектировали стандартные пакеты ас3.
а как было бы круто:
Код AS3:
public interface IWeapon extends IDisplayObject {}
Но остается только мечтать.

Wolsh 28.10.2013 15:40
Цитата:
Но остается только мечтать.
Не понимаю. И что даст этот интерфейс? Интерфейс говорит о том, какие методы есть У объекта. Он НЕ говорит о том, что другой объект может сделать с экземпляром интерфейса. То есть интерфейс не позволит Вам делать addChild() для его представителя.
Если рассматривать интерфейс-метку типа IBitmapDrawable, который как раз говорит что можно сделать С объектом, то я, конечно, извиняюсь, но вот создадите Вы наследника EventDispatcher к примеру, и пометите его как IBitmapDrawable (или IDisplayObject). И что?
Дело не в "планировании классов", а в технической невозможности отображать "то, не знаю что". DisplayObjectы это сущности плеера, а не языка, и создавать свои Вы не можете технически. Природа Интерфейса же такова, что ЛЮБОЙ объект может подписаться его реализовывать. Это противоречие нерешаемо. То есть, решаемо тем, что такого интерфейса нет. Потому что его в принципе нет. Технически.

Dukobpa3 28.10.2013 15:50
Цитата:
И что даст этот интерфейс?
То же что и битмап дровабл.
А что дает IEventDispatcher?
В нашей ситуации пример с дроваблом - более подходит.
Суть то та же. "Нечто, которое можно отрисовать". Только в случае с дроваблом - на битмапу. А в случае с ДО - добавить в ДЛ.
Во всяком случае, с текущей архитектурой это, скорее всего, не решаемо. Но я уверен что это не настолько уж проблематично было предусмотреть изначально.

Wolsh 28.10.2013 16:01
Ну ты отрисуй в битмапдату наследника диспатчера для примера)
Метка она и в Африке метка. Решение "на коленке" было сделано, чтоб битмапдату отрисовывать. По сути тоже языка никак не касалось, но видимо не смогли ничего лучше придумать. Однако это не показатель, что надо продолжать совершать такие же ошибки))

Akopalipsis 28.10.2013 16:13
А мне лишь жаль, что нельзя наследоваться от DO для создания контейнера без всяческих излишеств.
Хотя возможно, что неиспользуемые методы и свойства супер класса не добавляются при компиляции.
Но у меня был момент, когда я смотрел, что из себя представляет класс унаследованный от Sprite через describeType..
Там так много всего.

Dukobpa3 28.10.2013 16:15
Лол, а я в дровабл не заглядывал никогда.
Он пустой, оказывается:)
Ну с такой реализацией нафиг не нужен интерфейс для до. Я просто думал там какой-то геттер выдающий как минимум шейп или хз.

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

alexcon314 28.10.2013 16:56
Типа вот так что ли?
http://dispatchevent.org/mims/idisplayobject/

Dukobpa3 28.10.2013 17:09
Цитата:
You would still have to type cast to DisplayObject to use this as an argument for addChild().
Цитата:
Requires you to use asDisplayObject() every time you want to use the object as a DisplayObject.
А смысл?
Это надо делать нативно со стороны платформы.
А костыли и велосипеды мы тут все изобретать умеем с разной степенью успешности. Только это далеко не всегда профит ожидаемый дает.

alexcon314 28.10.2013 17:44
Цитата:
А смысл?
Это я как раз к тому.
Цитата:
Это надо делать нативно со стороны платформы.
Интересно. Что вы подразумеваете под нативным интерфейсом IDisplayObject? Поясните? Не понятен ход ваших мыслей.

Dukobpa3 28.10.2013 17:48
вот то что по ссылке но с адекватной поддержкой со стороны плеера и стандартных библиотек.
Без кастов там где это не нужно.
Так как такой интерфейс как раз призван ибавить от кастов. Но получается то ради чего я бы это делал - не выполняется.

Wolsh 28.10.2013 18:51
Странно что надо повторять, у Вас как будто фокус зрения никак не соберется на этой простой вещи:
Интерфейс не говорит о том, что можно сделать с объектом, какому методу его можно передавать и т.п.
Интерфейс описывает методы самого объекта, а не методы, которые будут использовать этот объект.
Интерфейс никак не может описать addChild(), который можно применить к его имплементатору.
Интерфейс вообще в принципе не для этого. Щелкните уже переключателем.

Добавлено через 3 минуты
Цитата:
Так как такой интерфейс как раз призван ибавить от кастов. Но получается то ради чего я бы это делал - не выполняется.
Он призван избавить от кастов в ситуации, когда нужно гарантировать наличие метода у объекта. Избавить от кастов, когда нужен аргумент определенного типа, он никак не может. Это не входит в его задачи. Интерфейс не подменяет тип данных. Он сам и есть тип данных.

Dukobpa3 28.10.2013 19:13
Код AS3:
doc.addChild(child:IDisplayObject):IDisplayObject
instead
Код AS3:
doc.addChild(child:DisplayObject):DisplayObject
И всего-то.
НО это надо делать изначально со стороны платформы. Поэтому никаким костылем это не заткнется.

alexcon314 28.10.2013 19:37
А.. кажется понял..
IDisplayObject - пустышка типа IBitmapDrawable? Действительно, просто.. и не нужно.
Но вы же говорили про какие-то геттеры, возвращающие "шейп или хз". Вот этот момент интересен. Как этот возврат будет работать нативно? Не понятно.
ЗЫ.
Занятно, таким макаром можно было бы потребовать ISocket, IURLLoader, IByteArray ... красота!

Dukobpa3 28.10.2013 19:45
Цитата:
IDisplayObject - пустышка типа IBitmapDrawable?
Я не знаю как вам объяснить.....
Я как раз о том что пустышка не нужна.
И костыль-велосипед тоже не нужен.
Но поддержку на уровне платформы сделать можно было. И не пустышками-тегами.
И если бы у меня интерфейс потребовал геттер шейпа, который позволит этот шейп добавить на сцену.
И если бы я выдал пустой шейп - то система бы не сломалась. А то что шейп пустой - было бы на моей совести.

Но сама гипотетическая возможность интересна.

Добавлено через 2 минуты
Цитата:
ISocket, IURLLoader, IByteArray
А почему нет?
java вся на интерфейсах и ниче, жива.
Местами перебор конечно, тем более с их нейминг конвеншном (без префикса "I" и "A") - но тем не менее.
Я при наличии прямых рук могу всё что угодно реализовать и не сильно прыгая с бубном.

Babylon 28.10.2013 21:06
Одна из задач интерфейсов - скрывать реализацию и принуждать использовать только те методы которые в нем описаны, а насчет API у вас могут разные API - vk,ok,fb & ets. Это я про унификацию продолжаю. А извращаться можно и не так как показывал дукобраз. К сожалению, интерфейсы нельзя программировать, но ручками оно понятно надежнее.

Wolsh 28.10.2013 23:37
Dukobpa3, без проблем))
Код AS3:
package 

{

        import flash.display.DisplayObject;

 

        public interface IDOCAddable 

        {

                public function get view():DisplayObject;

        }

}
Код AS3:
package 

{

        import flash.display.DisplayObject;

        import flash.display.Sprite;

 

        public class ChildDO extends Sprite implements IDOCAddable 

        {

                public function ChildDO() { }

 

                /* INTERFACE IDOCAddable */

 

                public function get view():DisplayObject 

                {

                        return this;

                }

        }

}
Код AS3:
package

{

        import flash.display.Sprite;

 

        public class MainClass extends Sprite 

        {

 

                public function MainClass() 

                {

                        addAsChild(new ChildDO());

                }

 

                private function addAsChild(child:IDOCAddable):void 

                {

                        this.addChild(child.view);

                }

        }

}


Часовой пояс GMT +4, время: 01:08.
Страница 2 из 3 < 1 2 3 >
Показывать 40 сообщений этой темы на одной странице

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.