Не могу разобраться в интерфейсах

[54321go]

Подскажите пожалуйста. Почему интерфейс не работает? Исходник прикрепил.
Главный класc у меня main. Как я понял он должен вывести "Eat", но выскакивает ошибка 1061.

[Wolsh]

IEat.traceEat()

?
Интерфейсы не содержат реализацию.
Интерфейсы не имеют отношения к статике.
Почитайте http://flasher.ru/forum/showthread.php?t=157498

[MINASTIS]

Если честно тоже недавно пришел к интерфейсам и не прочь вбросить словечко.
Лично мое понимание их существования (дабы не апать тему что выше указана) - логика написания кода.
Для удобства и построения логики приложения\сайта\чего угодно. Если есть интерфейс - он словно делает метку, такие-то такие-то методы должны к примеру быть. Интерфейс dragable там, killable (в случае игры) и т.д.
Просто для логики построения во время кодинга.
Удобная вещь, кстати.

[elder_Nosferatu]

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

[caseyryan]

Просто для логики построения во время кодинга.

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

Есть, допустим, в в игре разные виды машин, Jeep, Convertable, FamilyWagon ... или даже другая техника, управляющаяся так же. Они все при этом могут применять один интерфейс, например IControllable, в котором прописаны общие для них всех методы, drive(), steer(), inginte() ...
и в коде можно будет узнать что за объект нам попался, лишь проверив его интерфейс

if (obj is IControllable) {
   (obj as IControllable).drive();
}

Я уже давно не представляю себе кодинга без интерфейсов

[zerAlex2]

Есть простенький пример? Интересно посмотреть его в работе.

[Wolsh]

caseyryan, как верно отметили в той теме, подобные примеры запутывают, потому что такое поведение можно (и нужно) реализовывать наследованием, а не интерфейсами. Это — лишь одно из нескольких применений, и не самое удачное (всякий, кто принимал в метод объект по интерфейсу и потом пытался добавить его в отображение, поймёт о чём я).
1. Инкапсуляция. Интерфейс позволяет скрыть публичные методы (включая сеттеры и геттеры), доступ к которым не нужен клиенту интерфейса. Например, Модель может предоставлять один интерфейс Контроллеру, и совершенно другой — Вьюхе. Потому что Вьюхе совершенно не надо иметь доступ к управляющим функциям Модели, а Контроллеру — к её геттерам.
2. Объединение в один Тип нескольких Классов с несовпадающей цепочкой наследования ("замена множественному наследованию", как это часто ошибочно называют). Стандартный пример — задача сохранения состояния игры, когда нужно пробежаться по всем объектам и сохранить их описание. Все объекты совершенно разных классов, в том числе недисплейные, но все имеют одинаковый метод describe(), возвращающий описание состояния объекта (в XML, JSON или другом формате), по которому этот объект можно будет восстановить в будущем. Без интерфейсов такая задача может стать реальным кошмаром. Наследование здесь совершенно бессильно.
3. Маркер, или пустой интерфейс. Интерфейс, в котором не описано ни одного метода, потому что он говорит о том, что можно сделать с данным объектом, а не что "умеет" делать объект. Пример — интерфейс IBitmapDrawable, которым "помечены" все наследники DisplayObject и класс BitmapData, не являющийся дисплейным (не наследующий DisplayObject). Интерфейс сообщает, что эти объекты могут быть отрисованы в битмапДату. При этом сами объекты не обязуются реализовывать какие-то особые методы.
4. Гарантия наличия методов на этапе компиляции. Или просто "напоминалка" для себя или членов команды.
5. Основное средство на этапе проектирования.

Добавлено через 22 минуты
Простой пример? Ну вот например два класса с разной цепочкой наследования, Спрайт и Саунд, реализуют один интерфейс ITestable, что гарантирует наличие у обоих метода test():void
ITestable.as

package  
{
	public interface ITestable 
	{
		function test():void;
	}
}

TestSound.as

package  
{
	import flash.media.Sound;
 
	public class TestSound extends Sound implements ITestable 
	{
 
		public function TestSound() {}
 
		/* INTERFACE ITestable */
		public function test():void 
		{
			trace("I'm TestSound!");
		}
	}
}

TestSprite.as

package  
{
	import flash.display.Sprite;
 
	public class TestSprite extends Sprite implements ITestable 
	{
		public function TestSprite() {}
 
		/* INTERFACE ITestable */
		public function test():void 
		{
			trace("I'm TestSprite!");
		}
	}
}

Main.as

package 
{
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class Main extends Sprite 
	{
 
		public function Main():void 
		{
			testObject(new TestSound());
			testObject(new TestSprite());
		}
 
		private function testObject(object:ITestable):void
		{
			object.test();
		}
	}
}

[caseyryan]

потому что такое поведение можно (и нужно) реализовывать наследованием, а не интерфейсами.

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

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

[Wolsh]

Наследованием? И делать кучу оверрайдов когда нужно, чтобы метод с одним и тем же названием реализовавывал совершенно разное поведение?

В этом и состоит смысл наследования. В выделении (абстрагировании) общих постоянных и мутабельных составляющих Объекта. Вы привели в пример машинки, и да, гораздо логичней все их унаследовать от класса Транспорт, который умеет двигаться и перемещать другие объекты. По той простой причине, что их цепочка наследования идентична, они все Спрайты или Мувиклипы. Создав абстрактный класс АМашина, расширяющий Спрайт и добавляющий методы движения, ремонта, заправки и т.д., вы сделаете половину работы над остальными классами машин.
А "методы с одним и тем же названием" будут реализовывать у Вас "разное поведение" что с интерфейсом, что с наследованием. Зато одинаковое поведение не надо будет копипастить в каждый класс. Плюс по слову override Вы всегда будете видеть, какое поведение данного подкласса отличается от стандартного.
Именно применение здесь интерфейсов запутывает "новичка", потому что никак не отвечает на вопрос "зачем нужны интерфейсы". Он моментально столкнется с проблемами, вроде постоянного кастинга обратно к классам, и так и останется при мнении что интерфейсы "непонятное заумное зло".

Ваши примеры для новичка еще более запутаны.

Интерфейсы — инструмент ООП. О каких новичках речь? Для новичка в принципе запутано, зачем прятать какие-то методы и свойства, а тем более публичные. Новичок ставит везде модификатор доступа public и в ус не дует. Вы можете пятитомник написать об интерфейсах для новичков, но 4 тома из них будут об ООП. Для понимания нужен качественный скачок. Это слишком сложно для формата форума. Единственное, что можно объяснить новичку — это маркеры и напоминалки. Объяснение про Типы уже требует понимания Типов, Наследования, Абстрактных Классов и других концепций.

Всему свое время.

"Первые два года мы учим наших детей ходить и разговаривать, а потом до самого совершеннолетия только и орём на них: «Сядь и заткнись!»" © Ozzy Osbourne

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

Добавлено через 3 часа 58 минут
Да, если по какой-то причине про маркеры непонятно получилось, то вот пример применения "своего маркера".
Допустим есть игра, в которой есть армия игрока и армия врагов. Причем армия включает множество классов техники и солдат. После некоего "хода" должна происходить проверка ячеек карты. Нам пришлось бы перебирать все классы вражеской армии, чтобы просто определить, что объект в ячейке — враг.
"Если(объект это ТанкПантера ИЛИ объект это НемецСГранатой ИЛИ объект это ЭсэсовецСНожом ИЛИ...)"...
Достаточно пометить все вражеские классы интерфейсом-маркером INaziForce, а "свои" — IStalinForce, и определение врага сведется к "Если(объект это INaziForce)".
При этом интерфейс не требует от классов вообще никакого поведения, то есть он пустой. Просто метка, группирующая множество различных Классов в один Тип.
Ну а можно конечно упрямо копипастить во все вражеские классы геттер forceOwner, возвращающий "Nazi".
Но маркер в сто раз красивее идеологически. Он именно "объединяет")))

[MINASTIS]

Вообще про интерфейсы вполне водробно расписано в Колине Муке, по крайней мере в тех первых главах про ООП.
Про использование - согласен с тем, что человек сам поймет, когда это удобно.
Я, например, читаю Мука по той причине, что мой прошлый опыт работы с АС был "кадры, ас2, мувиклипы и т.д." что просто взрывало мне мозг. Сейчас же, благодаря знаниям ООП, я написал простенькую, к примеру, галерею, полностью с классами, не нарисовав ни одного кадра или вообще чего-либо на сцене руками. Фла просто для проекта сидел в папке и все. Остальное код. И все работает. И для понимания проще и удобнее.

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