Помогите разобрать понятие интерфейса

[Dukobpa3]

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

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

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

[Babylon]

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

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

[Котяра]

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

Масло масляное.
API - Application Public Interface

[Psycho Tiger]

В контексте масла этот кусок меня куда больше смущает

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

Вот получили мы с тобой интерфейс IWeapon, будем строгать для игры пушки. Реализовали, сделали. Я унаследовал свою пушку от Sprite, а ты от XML. Чья пушка вызовет эксепшн при добавлении в дисплай лист?
Значит, для примера куда больше подходит псевдоабстрактный класс, унаследованный от DO.

Если сторонний класс не имеет нужных Вам интерфейсов (их может быть несколько) Вы, используя фабрику, наделяете его нужным интерфейсом.

Метопрограммирование – это чудесно, но, к сожалению, в языке оно развито так же плохо, как и лямбды.
Фабрика – как-бы-паттерн который создаёт экземпляры в рантайме. Поделись опытом, как в рантайме наделять классами. Действительно ли оно стоит? Возможно, эффективней будет всё-таки выкинуть фабрику да писать классы в редакторе, по старинке, складывая головную боль на компилятор?

Новый класс как бы проксирует его.

Почему как-бы? Это и есть прокси. Причем в самом настоящем его оверхеде. Вместо реплики "а класс-то неизменен!" лучше изменить исходный класс – вот где ниндзюцу.
(да, не всегда есть доступ к исходным кодам других классов, но... Станиславский не поверит.)

[Dukobpa3]

Сообщение от Psycho Tiger

Я унаследовал свою пушку от Sprite, а ты от XML.

Вот здесь я в кои-то веки на сторону бабулона стану.
Это уже не косяк подхода, это косяк флеша, что он не имеет никаких интерфейсов для дисплей-листа, окромя IBitmapDrawable. Который, собственно, никуда не упирается абсолютно.
Несколько проектов подряд последних были модульные, и именно с такой постановкой задачи как озвучил бабулон. Часть модулей писали мы, часть аустсорсили.
Благо что каждый модуль это флешка, потому он просто физически не может быть ничем кроме спрайта. А если бы они колбасили нам допустим одну библиотеку в которой пачка классов-модулей - была бы *опа.

Но опять же повторюсь - это адобовцы косоруко проектировали стандартные пакеты ас3.
а как было бы круто:

public interface IWeapon extends IDisplayObject {}

Но остается только мечтать.

[Wolsh]

Но остается только мечтать.

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

[Dukobpa3]

И что даст этот интерфейс?

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

[Wolsh]

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

[Akopalipsis]

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

[Dukobpa3]

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

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