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

TanaTiX · 17.10.2010, 00:52

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

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

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

В общем надеюсь на помощь. Интересует как часто? когда? в каких ситуациях? какие при этом я получаю преимущества? (не зависимо от количества разработчиков

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

alatar · 17.10.2010, 01:01

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

MrPoma · 17.10.2010, 01:09

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

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

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

chabapok · 17.10.2010, 01:32

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

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

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

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

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

Bgg · 17.10.2010, 01:37

Цитата:

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

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

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

Wolsh · 17.10.2010, 02:35

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

TanaTiX · 17.10.2010, 03:13

alatar, как я понимаю в приведенном примере как раз наследование подходит лучше
MrPoma, спасибо за ссылку, читаю про SOLID.
chabapok

Цитата:

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

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

Цитата:

а типизацию переменных убрать

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

Цитата:

три --...

Т.е. следующий пример будет верен:
У нас есть массив(корзинка) продуктов: фрукты и овощи. Они могу быть красными, желтыми и зелеными. И мы вместо того чтоб заводить переменные, как подсказывает Wolsh, просто проверяем интерфесы, при этом можем сделать выборку как только овощей, так и красных овощей.
BggЯ как раз думаю, что не понимаю смысл интерфейсов, потому и создал тему.
Wolsh

Цитата:

Они могут вообще ничего не содержать

а как это будет соотносится с используемой памятью, производительностью?

Цитата:

Вам придется заводить его во всех 15-и классах

но ведь мне по аналогии придется во все 15 классов дописывать конструкцию типа "implements IClass". А вотношении суперкласса я также могу воспользоваться наследованием.

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

expl · 17.10.2010, 03:26

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

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

Код AS3:

public function get hintText()

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

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

Код AS3:

var button:IMyButton = ...
addChild(button as DisplayObject)

либо:

Код AS3:

var button:DisplayObject = ...
manager.addButton(button as IMyButton);

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

Код AS3:

interface IMyButton extends IDisplayObject

Вот так НЕиспользование интерфейсов ухудшает гибкость на примере API флешплеера

Wolsh · 17.10.2010, 04:22

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

Цитата:

но ведь мне по аналогии придется во все 15 классов дописывать конструкцию типа "implements IClass".

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

gloomyBrain · 17.10.2010, 05:38

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