Собственно, долго мучал этот вопрос. Сейчас, наконец-то приобрел в печатном варианте "PHP5: Power Programming". Прочитал про интерфейсы, я так понял что это полностью абстрактные классы, которые помимо названий методов могут включать себя предопределенные константы + класс может основываться сразу на нескольких интерфейсах, в отличие от классов.

Итак, я не понимаю, в чем плюсы использования интерфейсов:

Код и использованием интерфейсов:


Код без использования интерфейсов:


Может кто-нибудь привести пример, где интерфейсы действительно полезны?

Go discuss!

Добавлено через 2 минуты и 13 секунд
Вижу пользу в абстрактных классах, когда определен хотя бы один метод. А вот в интерфейсах не вижу, ибо они получается только тупо выступают шаблоном для написания класса :\ Или может это и нужно (при коллективной разработке), и так как я пишу один - мне этого не понять? 

на то он и интерфейс. ещё польза, это полиморфизм. хоят конечно они больше для организации кода.

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

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

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

Ну, я читал об этом, что в других ООП языках интерфейсы выступают в виде множественного наследования 

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

да. в тех, где оно не реализовано на классах.

ну ты самуже перечислишь use cases интерфейсов, то что они не нужны тебе лично, не говорит о том что они не нужны совсем.

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

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

sTa1kEr все очень хорошо рассписал на мой взгляд.

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

В PHP ввиду отсутствия строгой типизации надобность в интерфейсах практически отсуствует.

А разве интерфейсы это не "рычаги управления", которые могут представляться в любых формах, от физических слотов ПК, до пользовательских форм?

И ответ на то, нужны ли эти "рычаги" врядле можно строить основываясь на кол-ве кода. Зачастую лучше один раз написать лишние 100 строк, не ленясь, чем потом каждый раз возращаться к ним и дописывать по 20. 

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

Это сообщение отредактировал(а) BuShaRt - 23.9.2007, 23:58

Правильно ли (в итоге) я понимаю, что интерфейсы это: 

• инструкции по наличию методов и типов входящих переменных
• скелет для упрощения разработки

???

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

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

Уже поднимался такой вопрос.

Интерфейсы это чистейшей воды парадигма безопасного программирования/проектирования, при которой производятся проверки объектов на соответствие к определённой группе типов (классов), имеющих в наличии определённые методы (интерфейсы).  Интерфейсы просто определяют требуемые методы в себе, а реализующие классы обязаны их реализовать, сори за тавталогию 
Всё остальное в ссылке http://forum.vingrad.ru/forum/topic-265286...1912149/15.html.

По ссылке добавлю так же: не только type hinting, но и проверка возвращаемых значений-объектов на тип (name interface), если таковые были, гарантирует правильное функционирование потока сценария, так как соответствующие методы гарантировано существуют в объекте.  

Добавлено @ 23:22

Никогда они не выступали наследованием. Задающими реализацию да, наследованием нет.

Добавлено через 12 минут и 21 секунду

Да, но это больше проектрование не жели свойства программирования.

Это сообщение отредактировал(а) Sentox - 2.8.2012, 23:27

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

контроль типов в php (не вообще, а именно в php) довольно слабое утешение: в большинстве случаев ошибка типизации и так приведет к ошибкам исполнения, т.е. меняется только сообщение об ошибке и строка, где ошибка возникает. процент обнаружения ошибок (для чего, собственно, и нужна типизация) повышается, увы, незначительно.
это не значит что не нужно использовать средства типизации, в т.ч. интерфейсы, это значит что не стоит переоценивать их роль в техническом плане. а в плане проектирования они так же ценны, как и в других языках.

Это сообщение отредактировал(а) baldina - 3.8.2012, 12:01

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

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

У меня когнитивный диссонанс.

Вы программист или веб-разработчик?

с удовольствием и благодарностью послушаю что еще входит в эту область

Добавлено через 13 минут и 11 секунд

еще бы: зачем платить web-разработчику, если достаточно программиста   

Не стоит, лучше почитать повнимательней литературу (не следует меня относить к новокодерам) нежели Петросянить , это не сарказм и не прикол


Fortop, 
Ещё раз напомню дискуссия с Вами это дискуссия с ..... сложно сказать, со своим вторым Я, более получаса дискуссии превращается в поток "фекалий" да бы не вводить Вас в когнитивный дискомфорт думаю не вступать в дискуссию 

Ребята стоит более предпочтительно относиться к другим мнениям, да же если они звучат не с Вашей стороны, не стоит быть в оппозиции и иметь сторону "есть моё мнение и не правильное". Удачи 
Человек по ссылке, приведена выше, не мог понять именно по этой причине, что каждый гнул свою сторону.

Я так понимаю Вы baldina и Fortop фрилансеры по веб разработке и ничего да же не знаете про разделение труда в инженерии ПО, иначе как объяснить не понимание 

Тогда я замолкаю  перед Вашей "справедливостью"

Это сообщение отредактировал(а) Sentox - 3.8.2012, 22:10

Дабы отличать дискомфорт от диссонанса, возможно, вам стоит что-то почитать?


Ну....
Я якобы Team Lead
Видимо, мне положено не знать о разделении труда.

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

Литературу читал... немного... Вопрос мой был не на пустом месте, желаете - любопытство своё обосную.
А ответ Ваш напоминает ответы некоторых участников этого форума "сам знаю, но вам не скажу".


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


второй промах. я вообще к php да и веб разработке в целом имею весьма опосредованное отношение  

Хммм понятно .... это уже всё ставит на места.
Врач профессия абстрактная, хирург специализированная, хммм 
и не знать?

или может Вам не только начальные строки википедии.

Sentox, тут никто не объединяется в кланы что бы кого-то задавить. Мы общаемся, высказываем мнение, задаем вопросы.
Если мнение двух и более участников схожи, это скорее повод задуматься нежели подозревать сговор.
Я вот Вам задал конкретный вопрос. Либо мы говорим об одном, либо Вы неправы, либо я чего-то не знаю (и готов учиться).
Вы же вопрос просто отфутболили. Есть основания думать, что Вам просто нечего сказать, а признаваться не желаете.
Ничего личного.   

baldina, 
Честно я Вам напишу в личку, Вы правы я  
я уже модератору одному обещал давно давно ...  ни как времени не найду, извините я смогу сразу напишу в личку, ок ?

Это сообщение отредактировал(а) Sentox - 3.8.2012, 23:55

  
нет времени на пару слов по сути? время на длинные посты в разных топиках есть. что-то тут не сходится... ладно, почитаем личку...

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

в таком случае не стоит ждать

Это сообщение отредактировал(а) Sentox - 4.8.2012, 00:09

Если коротко то в PHP интерфейс не обязателен, но создавался он чтобы давать коротко информацию о списке доступных публичных функции, количество аргументов итд..., без подробного вникания в код. Которые будут написаны или уже написаны. 
Некто не запрещает 1 человеку написать интерфейс  для случая прихода нового человека в команду, чтобы быстро ввести в курс дела по интрефейсу. Или использовать для себя краткий справочник что есть, чем листать сотни строк кода.


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


Это сообщение отредактировал(а) Sanchezzz - 4.8.2012, 00:29

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

Это сообщение отредактировал(а) Sentox - 4.8.2012, 00:43

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

Имею дела с такими фреймворками как Yii и кохан повседневно ( гребенное наследство ).
Писать сайт на фреймворке круто или правильно как принцип и идею не поддерживаю.



Это сообщение отредактировал(а) Sanchezzz - 4.8.2012, 01:36

Да сам на Yii, но мне интересно и сам переопределяю API под себя, естственно не без разбора "старого" кода. Опять же фрейм тот же фундамент, как я всегда говорю хочешь на нём переделай структуру дома, но птнятное дело по контуру 

Быть может у нас разные понятийные вещи, но программист - это тот кто пишет программы.
Веб-разработчик - человек связанный с соответствующей отраслью и.... пишущий таки программы пусть даже в html/css (про php/js/python/ruby я молчу)


А я вам открою еще и секрет. Хирурги тоже бывают разные. Бывают пластические, а бывают и нейрохирурги.
А бывают еще и главные хирурги, которые даже и не оперируют.

Так вот team lead в ряде случаев вовсе не программист, если он не пишет код, то он намного ближе к project manager.
Впрочем, вам не повезло - я код пишу.


Не знать чего? Что вы несете чушь?
Знаю.


нам точно не надо.
Поскольку мы знаем, что диссонанс может не нести дискомфорта.
Комфорт и гармония это все же разные вещи.
А вот вам срочно надо заняться самообразованием.


P.S. 

Что-то обнадеживающее вычиталось?   

про интерфесы ничего нового. даже более строго: про интерфесы - ничего.

Добавлено через 4 минуты и 49 секунд

А. Степанов на встрече с коллективом Яндекс, где он впервые прочел свою коронную лекцию на русском, рассказал, как однажды на его лекции ему сделал замечание Д.Кнут. Замечание было справедливым, но Степанов выкрутился фразой