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

[Wolsh]

Crazy, в ответ на Ваше замечание к моему тексту пример псевдокода:

class Утюг implements ЯВРозетку220Втыкабельный, ЯОдеждуГладящий
class Паяльник implements ЯВРозетку220Втыкабельный, ЯПроводаПаяющий
class Ноутбук implements ЯВРозетку220Втыкабельный, ЯВИнтернетХодящий
class Мобильник implements ЯВИнтернетХодящий, ЯДрузьямЗвонящий

Понимаете разницу между "втыкабельный" и "гладящий"? Интерфейс не обязан описывать НАЗНАЧЕНИЕ, ибо в ситуации, когда метод ничего не возвращает, описать "назначение" невозможно в принципе. Назначение утюга конечно же не в том, что он втыкается в розетку. Но нет никакого смысла описывать назначение, что "утюг гладит одежду", если неизвестно, как заставить его это делать, как использовать класс в коде. Это и описывает интерфейс – наличие вилки на 220 к примеру, без которой Вы не сможете воспользоваться ЭТИМ утюгом для глажки. И хотя ваши паровые и чугунные утюги тоже гладят, у них именно другой интерфейс для операции нагрева. Они все могут реализовывать Интерфейс ЯОдеждуГладящий, содержащий метод

гладить(одежда:Одежда):ПоглаженнаяОдежда;

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

[fish_r]

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

... По факту, можно и штаны через голову надеть....

Не, а, правда. Пробовал? И что, получилось?!

[in4core]

ПОлучился холивар

[Crazy]

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

Интерфейс не обязан описывать НАЗНАЧЕНИЕ, ибо в ситуации, когда метод ничего не возвращает, описать "назначение" невозможно в принципе.

Что может быть приятнее, чем явить чудо.

/**
 * Вынимание меча из ножен.
 * pre: персонаж имеет меч
 * pre: меч находится в ножнах
 * post: персонаж держит меч в руке
 * invariant: количество предметов персонажа не изменилось
 */
function draw():void;

[Psycho Tiger]

Crazy, банально и на пальцах:
Вам поступило сообщение "Я сплю с твоей подругой".
Вопрос: а что же это значит?

Логика Ваша: ну, если спит, значит просто спит. Без вариантов.
Альтернативная логика: если я кот - то я просто сплю. А если я Вин Дизель - то не просто.


UPD: ох, ёлки, мне прислали ссылку на тему просто почитать, я подумал что актуально. Извиняюсь за некропост

[razerw]

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

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

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

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

if (e.target is IBlowable) {
      e.target.blow();
}

В этом случае нам не нужно будет проверять принадлежит ли цель к каждому конкретному виду техники, например так:

if (e.target is Car || e.target is Tank || e.target is Helicopter) {
      e.target.blow();
}

Кто-то возможно скажет: "но ведь можно же, например, првоерить e.target is DisplayObject"
И результат будет true. Но DisplayObject не имеет метода blow();


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

Объясните пожалуйста как тогда вызвать метод blow() конкретно у Car

[Wolsh]

У Класса Car, то есть статический метод класса? Этот вопрос не имеет отношения к интерфейсам. Интерфейсы не могут описывать статические методы.

[razerw]

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

У Класса Car, то есть статический метод класса? Этот вопрос не имеет отношения к интерфейсам. Интерфейсы не могут описывать статические методы.

нет я не про статический а публичный метод. я не могу понять в каждом из классе Car, Tank, Aaa и т.д есть один и тот же метод blow(); как же он работает? если в классе интерфейса IBlowable есть тоже метод blow().
как имплиментных классах вызывать этот метод ну или отправлять аргументы в него.

[KumoKairo]

как же он работает?

Как раз таки прелесть интерфейсов в том, что никому не известно как работают методы, указанные в интерфейсе. Это черный ящик, мы знаем только что, допустим, метод blow() не принимает входных агрументов и ничего не возвращает.

Объясните пожалуйста как тогда вызвать метод blow() конкретно у Car

var myLittleCar:Car = new Car();
myLittleCar.blow();
//Или так
var myLittleBlowableObject:IBlowable = new Car(); //С учетом что Car реализует IBlowable 
myLittleBlowableObject.blow();

[razerw]

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