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

[AlexCooper]

Сообщение от razerw

что тогда будет в таком случае.
я отправляю в метод blow() интерфейса IBlowable аргумент.
Но метод blow() имплементирова в классах Car, Tank. какая будет реакция? аргумент придет в оба класса? Car, Tank?

Нет. Интерфейс, это как инструкция для пользования. То-есть класс который "хочет" реализовывать интерфейс, 100% должен содержать описанные свойства и методы интерфейса который он реализовует.

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

[KumoKairo]

я отправляю в метод blow() интерфейса IBlowable аргумент.

Ошибка компиляции, метод blow не имеет входных параметров

[AlexCooper]

Как пример допустим у нас есть два класса ( пишу не для компилятора )

class DigitalClock implements IClock {
    public function showTime(time:Date):void {
        // и тут выводим время в цифровом формате, то-есть 10:23:33
    }
}

class MechanicsClock implements IClock {
    public function showTime(time:Date):void {
        // тут рисуем стрелочки и выводим время как на механических часах
    }
}

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

public interface IClock {
    function showTime(time:Date):void
}

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

 
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]

Сообщение от AlexCooper

Как пример допустим у нас есть два класса ( пишу не для компилятора )

class DigitalClock implements IClock {
    public function showTime(time:Date):void {
        // и тут выводим время в цифровом формате, то-есть 10:23:33
    }
}

class MechanicsClock implements IClock {
    public function showTime(time:Date):void {
        // тут рисуем стрелочки и выводим время как на механических часах
    }
}

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

public interface IClock {
    function showTime(time:Date):void
}

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

 
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]

addChild(clock);

Кстати тоже работать не будет, выдаст ошибку что не может добавить в дисплей лист объект, не наследующий DisplayObject. Как выход кастануть к дисплей объекту

addChild(clock as DisplayObject);

Но тогда есть вероятность получить null reference exception, да и вообще весь полиморфизм коту под хвост (может наш IClock выводит информацию о времени в консоль, и вообще не является DisplayObject, а мы его пытаемся в дисплейлист добавить?)

if(clock is DisplayObject)
{
    addChild(clock);
}

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

[Wolsh]

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

[KumoKairo]

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

[Wolsh]

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

[AlexCooper]

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

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

[Akopalipsis]

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