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

Можно, но:
1. Не всегда. Попробуйте сделать такой общий класс для Sprite и Bitmap.
2. Зачем, когда для этого есть интерфейс?

Это антипример из серии "любая аналогия хромает". Потребление энергии не является назначением этих приборов.

Правильный пример: у нас есть старинный чугунный утюг, электроутюг и сковорода. У нас есть интерфейс ФиговинаДляГлажки. Все три реализуют этот интерфейс, т.е. гладить можно и электроутюгом, и чугунным утюгом, и разогретой сковородой. Делают они это по-разному, но все выполняют один и тот же контракт -- глажку.

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

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

В скомпилившемся коде -- гарантирует.

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

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

Допустим диспатчат 2 разных класса одно событие и при этом оба класса применяют общий интерфейс (допустим ISomeInterface), но есть еще и другие классы, которые тоже диспатчат это событие. Нам же нужно делать что-то только с теми классами, которые применяют этот интерфейс.

Для большей наглядности, допустим есть игра, в которой есть различные виды техники, которую нужно уничтожать.
Все виды транспорта будут, естественно, принадлежать к разным классам (Car, Tank, Aaa и т.д.), но есть у них и одно общее, они все должны взрываться.
Для этого создаем интерфейс, например IBlowable, с методом blow();
И имплементим его во всех классах техники.
Теперь, при попадании бомбы в транспортное средство, мы можем проверить в обработчике события так:
В этом случае нам не нужно будет проверять принадлежит ли цель к каждому конкретному виду техники, например так:
Кто-то возможно скажет: "но ведь можно же, например, првоерить e.target is DisplayObject"
И результат будет true. Но DisplayObject не имеет метода blow();


Вот, как-то так. Надеюсь не слишком стремное пояснение :D

Да блин опять холивар развели )) в первых постах все пояснили что и зачем :) По факту, можно и штаны через голову надеть. Просто если хотите видеть красивый структурированный код = юзаем интерфейсы , там где это будет логично, а там где суперкласс - там суперклассы. Недавно была тема, я там пояснил = когда интерфейсы , а когда суперклассы.
В двух словах : superClass используем для объектов одного типа и имеющих одинаковые методы, лишь мельком различающиеся ( тут оверрайдим) , интерфейс когда объекты РАЗНЫХ типов ( ваза, чашка, стакан, витрина ) но все они имеют один и тот же метод CRASH!

По поводу аналогии с розеткой: В глобальном плане она более правильная, чем аналогия с разными вещами для глажки, т.как интерфейс потому так и называется, что описывает способ общения с внешним миром (между поверхносями или между рельефами, ну как-то так), и не описывает, что он должен делать или для чего предназначен. CLI (Command Line Interface) не имеет конкретного назначения, вернее его назначение не более конкретно, чем назначение более широкого понятия, которое включает в себя CLI (общение с пользователем посредством командой строки)... Более того, это вполне себе правильно (предположим, в идиотской инструкции) сказать по-английски, что an electronic device interfaces with power supply through a socket in the wall (дословно: электроприбор взаимодействует с источником энергии через розетку на стене :)). Говорю я это к тому, что, в первую очередь, когда говорят об интерфейсе, то речь идет именно об интеракции / совместимости, а не о сериализации / категоризации. Второе часто бывает следствием первого, но первое не обязательно приводит ко второму, возможен обратный вариант, когда инструмент задействованный для интеракции приводит к дивергенции а не унификации.
В AS интерфейс выполняет дополнительно и функцию сериализации, потому что так реализован в языке, но это побочный эффект, более того, с некоторыми негативными последствиями, такими, как, например, два объекта, в принципе, предоставляющие одинаковый реальный интерфейс, предположим, у обоих наличиствует свойство graphics: Sprite и Shape, только потому что формально не реализуют один интерфейс, не могут быть переданы параметром в одну и ту же функцию.

EDIT: Вот, кстати, сейчас подумал: заглушка для розетки будет очень хорошим примером использования интерфейса т.как она никоим образом не является электроприбором, но реализует интерфейс розетки-штекера. :)

Пример с ручками, как раз и сбивает с толку, так как может быть выполнен обычным наследованием и перегрузкой метода write.