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

В очередной раз возвращаюсь к этой теме и пытаюсь найти плюсы для себя, как человека, в единственном лице работающим над к.-л. проектом.сКажите пожалуйста, есть ли смысл? Если есть - какие плюсы? Мое понимание ситуации на данный момент сводится лишь к тому что мне более чем достаточно будет наследование (extends), а интерфесы (interface) - лишние куски кода, которые в моем случае не нужны (т.к. над проектом работаю один).

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

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

В общем надеюсь на помощь. Интересует как часто? когда? в каких ситуациях? какие при этом я получаю преимущества? (не зависимо от количества разработчиков:) ) В общем буду благодарен за любые советы и мысли на тему интерфейсов. Спасибо.
====================
Upd. еще раз спасибо всем откликнувшимся. Думаю у меня еще будет повод отписаться :)

Представьте ситуацию, у вас есть n-е количество классов у которых нет общего предка, но у всех есть некий набор одинаковых методов и их надо обрабатывать. Тут уже просто наследованием не обойтись. Логичнее описать методы в интерфейсе и работать с объектами как с интерфейсом. Примеры IItemRenderer, IDataRenderer.

Использование или неиспользование интерфейсных классов это всего лишь проектировочный ход.

http://ru.wikipedia.org/wiki/Обращение_контроля

Чтобы разобраться в этом вопросе, рекомендую прочитать книжек, например, "Рефакторинг" (Мартин Фаулер).

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

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

три -- при помощи is можно проверять принадлежность переменной интерфейсу.
типа

if (clicketObj is ITransparentButton)clicketObj.alpha =1
if (clicketObj is IToolTip) clicketObj.showToolTip("Ахтунг!")

Часто так делать удобней, чем заводить внутри класса соответствующие флажки.

Если вы понимаете смысл интерфейсов, то зачем искать плюсы там, где для вас на данный момент их ещё нет? Это как с MVC, не всем нужно, но много кто знает и хотят его использовать.

То, о чем говорит chabapok в пункте 3 - называется еще Маркерами, или маркерными интерфейсами. Они могут вообще ничего не содержать == не требовать от классов реализации каких-то методов. Их смысл - просто дать понять другим классам, что с этими можно что-то делать (пример - IBitmapDrawable, который имплементят все ДисплейОбжекты). Допустим у Вас 15 наследников Спрайта, и Вы хотите разрешить только 4 из них растягивать по горизонтали, а остальные - нет. Помечаете четыре маркером - implements IHScalable, и перед попыткой растянуть такой спрайт спрашиваете, можно ли? Можно конечно завести булево свойство, но - незадача - Вам придется заводить его во всех 15-и классах, и во всех иметь это странное непрактичное свойство, к тому же вылезающее при автокомплите. Хороший пример - тот самый IBitmapDrawable. Представьте, что адобовцам пришлось бы во все(!) классы добавлять такой флаг - может или нет экземпляр быть отрисован в битмап. А тут просто пометили маркером один супер-класс и вуаля.

alatar, как я понимаю в приведенном примере как раз наследование подходит лучше
MrPoma, спасибо за ссылку, читаю про SOLID.
chabapok
Это удобно что? Как по мне множественное наследование классов было бы гораздо продуктивней при разработке. Или я не прав?
думаю в приведенном примере не совсем корректно, т.к. типизация есть в результате не только удобство, но и быстродействие на уровне откомпилированного приложения
Т.е. следующий пример будет верен:
У нас есть массив(корзинка) продуктов: фрукты и овощи. Они могу быть красными, желтыми и зелеными. И мы вместо того чтоб заводить переменные, как подсказывает Wolsh, просто проверяем интерфесы, при этом можем сделать выборку как только овощей, так и красных овощей.
BggЯ как раз думаю, что не понимаю смысл интерфейсов, потому и создал тему.
Wolsh
а как это будет соотносится с используемой памятью, производительностью?
но ведь мне по аналогии придется во все 15 классов дописывать конструкцию типа "implements IClass". А вотношении суперкласса я также могу воспользоваться наследованием.

Из того что понял на данный момент:
- полезно при первичном проектировании
- использование интерфейсов вместо булевых переменных

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

Пример, где наследование не справляется:
Например есть менеджер подсказок и ему нужно передать объект с полем hintText
(безобразное решение для огранизации подсказок, но сейчас не об этом)
надо показать подсказку и над классом, унаследованным от SimpleButton и над классом, унаследованным от Sprite, здесь мы не сможем впихнуть функцию:
в цепочку наследования
придется реализовывать этот метод и в MySimpleButton и в MySprite, а чтобы с ними обоими мог работать менеджер (без дурацких проверок на тип и опасного приведения типов) пусть реализуют интерфейс IHintTextable

В этом плане очень сильно недостает интерфейса IDisplayObject (хорошо хоть IEventDispatcher сделали), т.е. сейчас у нас есть в проекте 2 gui библиотеки
и есть 2 типа кнопок.
Одни наследуются от Sprite, другие - от SimpleButton
У обоих кнопок единтсвенное значимое отличие от DisplayObject - наличие свойства "enabled"
Ну и всё - приплыли. Использовать одни и теже классы работающие с 2-мя кнопками нельзя (вернее можно, но криво) - получается либо:
либо:
А все потому, что нельзя написать, нет интерфейса:
Вот так НЕиспользование интерфейсов ухудшает гибкость на примере API флешплеера

))Безусловно маркеры - НЕ главное, скорее даже одиозное применение интерфейсов (впрочем же адобовцы его не чураются). Может быть, их прямое назначение не вызывате у меня вопросов, поэтому заострил внимание на маркерах - автор спрашивал "зачем надо".
Вы не поняли. В том то и дело, что Вам надо будет только пометить 4 класса, что они "могут расширяться по горизонтали", а с остальными 11 делать ничего не нужно. Точно также как два адобовских класса имплементят IBitmapDrawable и только их (и их наследников) можно передавать в BitmapData::draw(). Все остальные классы вовсе не помечены каким-нибудь IDontBitmapDrawable. Их "НЕ" содержится в том что они НЕ реализуют IBitmapDrawable. Вот если бы Вы заводили поле - то да, у всех 15-ти, иначе как спросить?)) Через hasOwnProperty? Куда уж кривее - заводить поле, чтобы спрашивать не его значение, а - есть ли само поле))).
Основная задача интерфейсов, кроме собственно гарантии наличия методов - объединение того, что не может наследоваться от одного предка, как в случае с DisplayObject и BitmapData. В нередких случаях, когда есть какой-то контейнер (пакер), в который могут добавляться РАЗНЫЕ объекты (виджеты), имеющие интерфейс - т.е. методы - для работы в этом контейнере, Интерфейсы незаменимы. Многоуровневое меню, где пунктом может быть как кнопка, так и другое меню; статусБар - эта панелька внизу многих приложений, в которой помещается несколько Информеров - координаты мыши, подсказка к инструменту, индикатор прогресса, иконки дополнительных служб. Вы стали бы писать отдельный класс, чтобы все это унаследовать от него? А если таких интерфейсов понадобится пять - создавать цепочку из пяти суперклассов? Прелесть Интерфейсов в том что один Класс может реализовывать их несколько сразу, плюс наследовать.

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