Вообщем, мне надо как-то очень просто, лаконично, четко и так, чтобы стало очевидно, объяснить, зачем нужны интерфейсы объектов и с чем их едят. Вот пример с пхп.нет: Код (Text): interface iTemplate { public function setVariable($name, $var); public function getHtml($template); } class Template implements iTemplate { private $vars = array(); public function setVariable($name, $var){ $this->vars[$name] = $var; } public function getHtml($template){ foreach($this->vars as $name => $value){ $template = str_replace('{' . $name . '}', $value, $template); } return $template; } } Ну и что? Я нихера не понял! Ну в интерфейсе две функции, которые ничего не делают (мы их просто описали) и в классе эти же функции. И что дальше? Возьму удалю интерфейс, но всё будет работать без проблем! В чём прикол? Не, ну или опишите мне реальную ситуацию, где без интерфейса объекта ну никак.
Интерфейсы позволяют тебе гарантировать, что какой либо используемый объект реализует минимально необходимый набор функций. Суть в том, что пока ты пишешь программы сам, ты можешь договорится сам с собой о интерфейсе к чему либо, если же разрабочиков несколько, и тебе нужно контролировать код, который еще не написан, и будет написан не тобой. Хороший пример, реализация плагинов: ты описываешь интерфейс, в нашем случае, это будет IPlugin, например: PHP: <?php interface IPlugin { function register(array $config); function unregister(); function process($data); } И ты получаешь интерфейс плагина, и знаешь, что плагин будет реализовать эти три обязательные функции для работы. И можешь больше не думать о том, как обработать корректно ошибки, написанные автором очередного плагина. И можешь в исходном коде проверить, правильный ли это плагин, и от твоей ли он системы: PHP: <?php class UserPlugin() {} if (!in_array('IPlugin', class_implements('UserPlugin'))) { echo 'Неправильный формат плагина!'; } На самом деле, интерфейсы становятся очень нужны при использовании многих паттернов категории Inverse of Control, того же Dependency Injection, но это уже совсем другая история, не для изучающих основы PHP =)
флоппик, спасибо за простое объяснение. Просто, никогда не приходилось участвовать в проектах, где нужно разделять задачи с несколькими программистами Вообщем, мне этого объяснения достаточно, тему можно считать закрытой.
Просто я знаю, что вменяемого описания "зачем нужны интерфейсы" я за все время ни разу не встретил ни в одном учебнике или нормальной статье.
Вот поэтому я и задал этот вопрос, да еще и в разделе «для блондинок» — я тоже абсолютно нигде не встречал нормального объяснения. Все в статьях приводят каие-то примеры и т.д, но абсолютно нигде не было строчки подобной этой — «Суть в том, что пока ты пишешь программы сам, ты можешь договорится сам с собой о интерфейсе к чему либо, если же разрабочиков несколько, и тебе нужно контролировать код, который еще не написан, и будет написан не тобой.» Вот если бы таким нормальным языком было написано, на том же пхп.нет, я бы никогда не задавал таких вопросов
Немного отвлекаясь от PHP. Если взять Java, то там еще как минимум один мощный способ использовать интерфейсы. В Java нельзя создать объект типа интерфейс, однако можно преобразовать объект, класс которого реализует интерфейс, к этому интерфейсу. Зачем? Для увеличения гибкости метода. Так например есть метод "поджечь". Входным параметром метода является объект, который зажигает. Например "Зажигалка". Таким образом мы можем создать метод - Код (Text): поджечь(Зажигалка мояЗажигалка) По сути нам нужно от объекта реализации всего лишь одного действия - "зажигать". И нам абсолютно все равно какие у него свойства. Однако таким объявлением мы запрещаем передавать любые другие объекты, которые не являются "Зажигалками" или потомками "Зажигалки". Вот здесь может пригодится интерфейс. Мы создаем интерфейс "Зажигатель" с единственным методом "зажги". А далее говорим что "Зажигалка" реализует этот интерфейс. А еще мы говорим что "Танк" тоже реализует метод "зажги". Изменяем объявление метода Код (Text): поджечь(Зажигатель мойЗажигатель) и теперь мы можем передавать этому методу хоть "Зажигалку", хоть "Танк", хоть "ГазовуюПлиту" причем реализация метода "зажги" будет зависеть от того, какой объект мы передали. Правда и сделать с этим объектом мы сможем только то что объявлено в интерфейсе "Зажигатель"
Вот хороший пример, как люди, которые умеют программировать, не умеют обьяснять. Ты в который раз, как во всех учебниках, обьяснил "как это сделать", но не обьяснил "почему и зачем" это приходится делать на реальном примере, который показал бы востребованность интефейсов.
флоппик я тоже всегда вхожу в ступор когда думаю как же объяснить необходимость интерфейсов реально. Это надо объяснять на примере двух разных модулей скорее всего.
Костян ты какой день подряд отмечаешь новый год? написали же Для меня интерфейс - это тип. Такой же как int, string, array etc. Т.е. это декларация того, что данный код будет себя вести прогнозируемым образом
Simpliest ну или суть в том, что без раницы пишешь ты программы сам или нет, с помощью интерфейса ты можешь декларирорвать способности полиморфизма.
может поможет (простой пример): PHP: <?php // то, что давно написано и мы можем использовать interface IOperation { public function operation($a, $b); } // то, что мы написали сами class MySum implements IOperation { public function operation($a, $b) { return (int)$a + (int)$b; } } // то, что мы написали сами class MyMult implements IOperation { public function operation($a, $b) { return (int)$a * (int)$b; } } // где-то в другом давно написанном коде и хорошо работающем function doOperation($isum, $a, $b) { if (!($isum instanceof IOperation)) return; echo "<p>" . $isum->operation($a, $b) . "</p>\r\n"; } // наши вызовы doOperation(new MySum(), 3, 4); doOperation(new MyMult(), 3, 4); ?> Ща попробую по-простому (на самом простом примере). Предположим: doOpearion выводит результаты нашей могучей мозговой деятельности на вэб (проверяет результат, смотрит в кэш, формирует страницу из темплейтов и тд и тп). Наша задача только менять значения. А на все остальную работу не влиять никак. поэтому нам достаточно передать свой класс в качестве параметра, который гарантировано реализует те функции, которые нужны будут давно написанному коду (который хорошо работает). некое API. чОрт, я старалсО.
obsrv Люди приходят к пониманию, "как это сделать" с учебником, или без, если понимают, зачем это делать вообще. ) Поэтому говорю еще раз: для объяснения - абстрактные примеры - не работают.
м, интерфейсы - тема ацки удобная.. так как даже своя с нуля писанная система через 3-4-6 месяцев - как чужая... и черт его знает, что там у модулей обязательным должно быть... а так, даешь ему интерфейс, если не соответствует хоть в малом - с ходу дает fatal error, а не так, что в самый ответственный момент вдруг не понятно откуда сыпется ошибка.. жаль, что в интерфейсах нельзя описывать атрибуты для класса..
я не знаю просто как это объяснить человеку который впервые слышит слова "интерфейсы" в обсуждаемом контексте...
Чтобы человек легко понял, как кусок по-сути бесполезного кода может быть интерфейсом, ему сначало надо привыкнуть к тому, что кусок полезного кода может быть объектом. Если попробовать ручку от холодильника (интерфес) приделать к неподходящей модели холодильника (объект), то возникнет ошибка (нет нужных креплений). Если ручка подошла, значит холодильник правильный.
Simpliest может, моя особенность, я с помощью интерфейсов стандартизирую классы.. так, например, есть системка, построенная на паттерне MVC. в итоге контроллеры должны соответствовать интерфейсу контроллеров, модели - моделей и т.п. не все можно в классы-родители вынести. так, для примера. контроллер обязательно должен реализовывать несколько функций. у каждого они разные по содержанию, но должны быть у всех. а месяцев через несколько это имеет свойство забываться. и всплывать в самый неподходящий момент в виде плавающей критической ошибки... а атрибуты да, их можно в классе-родителе задавать..