Вобщем (не считая маркеров - это НЕ главное их применение) интерфейсы применяются там где:
- не справляется наследование,
- чтобы "сузить" интерфейс (чтобы клиент класса не дергал методов, которых его трогать не просят),
- чтобы сделать части системы максимально независимыми
Пример, где наследование не справляется:
Например есть менеджер подсказок и ему нужно передать объект с полем hintText
(безобразное решение для огранизации подсказок, но сейчас не об этом)
надо показать подсказку и над классом, унаследованным от SimpleButton и над классом, унаследованным от Sprite, здесь мы не сможем впихнуть функцию:
Код AS3:
public function get hintText()
в цепочку наследования
придется реализовывать этот метод и в MySimpleButton и в MySprite, а чтобы с ними обоими мог работать менеджер (без дурацких проверок на тип и опасного приведения типов) пусть реализуют интерфейс IHintTextable
В этом плане очень сильно недостает интерфейса IDisplayObject (хорошо хоть IEventDispatcher сделали), т.е. сейчас у нас есть в проекте 2 gui библиотеки
и есть 2 типа кнопок.
Одни наследуются от Sprite, другие - от SimpleButton
У обоих кнопок единтсвенное значимое отличие от DisplayObject - наличие свойства "enabled"
Ну и всё - приплыли. Использовать одни и теже классы работающие с 2-мя кнопками нельзя (вернее можно, но криво) - получается либо:
Код AS3:
var button:IMyButton = ...
addChild(button as DisplayObject)
либо:
Код AS3:
var button:DisplayObject = ...
manager.addButton(button as IMyButton);
А все потому, что нельзя написать, нет интерфейса:
Код AS3:
interface IMyButton extends IDisplayObject
Вот так НЕиспользование интерфейсов ухудшает гибкость на примере API флешплеера