Понять интерфейсы

[alatar]

как я понимаю в приведенном примере как раз наследование подходит лучше

Видимо недостаточно ясно выразился. В приведенном примере не может быть использовано наследование. Например интерфейс IClone может быть реализован как в визуальном, так и в не визуальном классе. В случае ItemRenderer, IDataRenderer, компонент не может заранее знать, от какого предка будет наследоваться визуализатор.

[TanaTiX]

Ответов много, и они объемные, за что отдельное спасибо, поэтому буду отвечать постепенно (к тому же если никто не ответит - они автоматом в конец дописываются)

expl

пусть реализуют интерфейс IHintTextable

Т.е. в классах MySimpleButton и MySprite я прописываю "immplements IHintTextable", но ведь и затем мне все равно придется написать в каждом классе все функции, объявленные в интерфейсе? Т.е. получается опять защита от склероза

А все потому, что нельзя написать, нет интерфейса:

А вот допустим мы написали таким образом и у нас есть IDisplayObject, как тогда дальше?
По поводу тех 2х примеров с интерфейсами (не совсем понимаю их работу):
1) мы создаем переменную, которая по сути является интерфейсом. Мы разве можем добавить на сцену интерфейс, даже с учетом приведения типов? Что вообще получится в результате? Мне почему-то казалось, что мы не можем добавить интерфейс на сцену, а если и можем, то какой в этом смысл, ведь там ничего кроме списка объявленных методов с атрибутами и переменных ничего нет.
2) Тут получается мы сразу добавляем интерфейс, т.е. к нему приводим и все это в каком-то контейнере? Это какой-то хитрый контейнер или это может быть любой спрайт?
Такое впечатление, что мне еще рано вникать в нюансы с IDisplayObject, т.к. пока еще с основами не разобрался.

Добавлено через 13 минут
Wolsh

впрочем же адобовцы его не чураются

а можно примерчик глянуть? (интересное глянуть реализацию именно от адоба, по самому применению данной фичи вопросов нет)

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

[Wolsh]

а можно примерчик глянуть?

Вы как между строк читаете.. Я же привел Вам реальный пример - IBitmapDrawable. Его имплементят только два класса - BitmapData и DisplayObject (соответственно все его наследники).
У класса BitmapData есть метод draw(), который принимает как параметр - внимание - не DisplayObject, а именно интерфейс IBitmapDrawable, т.е. И битмапдату И дисплейОбжекты:

public function draw(source:IBitmapDrawable, matrix:Matrix = null, ...

Ваше представление о том, что Интерфейсы - только памятка разработчику в команде, очень далеко от действтельности. Это их тридевятое применение. Интерфейсы - один из основных инструментов ООП. При взаимодействии одного класса с другим важно не то, какой это класс, а реализует ли он необходимые для этого взаимодействия методы, то есть - Интерфейс. Сами классы могут быть совершенно разными. Ситуации бывают такими, когда эти классы могут быть и дисплейными и логическими, или базами данных, но поддерживать один интерфейс - например, сериализацию для сохранения их состояния.
Пример - сейвы в игре. Вам надо описать в этом сейве состояние сотни объектов, четверть которых вообще не является дисплейными, например списки инвентаря, и имеет абсолютно разные параметры для сохранения. Все они должны иметь метод serialize():XML (XML это к примеру, формат тут не важен, но он один для всех). Менеджер сохранений проходится по списку подлежащих сохранению объектов и запрашивает у каждого сериализацию - некий набор данных, описывающий все параметры, необходимые для последующего восстановления текущего состояния этого объекта. Классы - самые разные. Все, что требуется - реализация интерфейса, т.е. наличие метода serialize, возвращающего данные в условленном формате. Ясно понятно, что Вы не будете наследовать сто совершенно РАЗНЫХ классов от одного - у Вас это просто НЕ ПОЛУЧИТСЯ, потому что наследование идет только по цепочке. Но Вы можете задать всем этим классам отдельный тип - интерфейс, гарантирующий наличие у них метода для общения с менеджером сохранений. "Гарантирующий" потому, что Класс не будет скомпилирован, пока в нем не будет метода, требуемого Интерфейсом.

[TanaTiX]

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

Я правильно понял? Или еще не дошло?

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

[Котяра]

У интерфейсов есть один недостаток - это усложнение ревью/ревизии кода, хотя это касается не только интерфейсов, но и использования в качестве аргументов базовых классов (особенно если они во многом абстрактны)
Тяжело без реальной sequence diagramm понять какой код выполняется.

[Wolsh]

На самом деле, насколько я знаю, Flash-девелоперы интерфейсами пользуются довольно редко. Все-таки смысл их раскрывается только в более-менее сложных ООП-проектах, да и традиционное отношение сказывается)) Когда вы пять лет флешерили без интерфейсов, взять и вдруг начать ими пользоваться по полной слегка затруднительно.
Да, TanaTiX, все базовые предназначения Интерфейсов Вы перечислили. Надеюсь, новое понимание Вам когда-нибудь поможет)) Удачи!

[expl]

получается опять защита от склероза

Как-бы если не исользовать интерфейс,
внутри менеджера пришлось бы писать так:

    public class HintManager
    {
         ...
         public function addElement(element:*)//<-- здесь мы не можем указать тип,
                         //котрый устраивал бы и компонент,
                         //наследуемый от SimpleButton и компонент наследуемый от Sprite и 
                         //имеющий при этом поле getHintText(),
                         //НЕ использовав интерфейс - нет других путей просто
         {
              ....
          var hintText:String = element["getHintText"]();

Тогда давай кодить на as1 уже.

Ну или более сурово:

    public class HintManager
    {
         ...
         public function addElement(element:*)
 
         {
              ....
              if (element is MySimpleButton)
              {
                   (element as MySimpleButton).getHintText();
              }
              ele if (element is MySprite)
              {
                    (element as MySprite).getHintText();
              }
              ...
              // Теперь отстается только порадоваться тому, что если появится еще
              // какойнить элемент с getHintText(), наследованный от Shape или Bitmap
              // придется добавлять сюда еще одну веточку if-а

Интерфейс - это такой же тип как и класс, только свободный от рамок НЕмножественого наследования и от реализации.

[iNils]

интерфейсы применяются там где:
- не справляется наследование,

Забудьте про связку наследование - интерфейсы. Это миф.

[expl]

Можно ссылочку поподробнее, где развенчивается этот миф?

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

А если нам надо расширить интерфейс(опять НЕ всмысле "интерфейс") класса в 2-х независимых веточках наследования - мы используем интерфейс (всмысле public interface ISomeInterface)

Как могут эти два понятия не быть связанными?

[TanaTiX]

expl

var button:IMyButton...

Я так понимаю аналогом данной конструкции без интерфейса было бы

var button:*...

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