Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 132
сейчас придут быдло кодеры и скажут, что интерфейсы - бесполезнео зло, да и вообще веб для ооп - не место, городить классы - признак помешанности, и вообще проще написать одну большую функцию, котоорая будет делать все.
зачем так бояться быдлокодеров?
пусть скажут ^_^
пусть скажут ^_^
чем Интерфейсы заменяют Абстрактные классы в PHP?
Хотя бы тем, что это две разные чтуки по сути. И хотя бы тем, что один класс может имплементировать несколько интерфейсов, а наследовать может только один абстрактный класс
Интерфейс по сути - это абстрактный класс, содержащий только абстрактные методы. Еще можно от нескольких интерфейсов "наследовать"
Использую, но они сильно тормозят приложения
А есть какие-нибудь цифры (хотя бы примерные)?
неправду говорите, особено в слове сильно. ибо интерфейсы — это в основном проверки на этапе компиляции и редко на этапе исполнения. Нельзя ж так обманывать
Это основано на моих тестах, может они и не обьективны, но моё мнение изменить могут :)
Да, в целом так.
Но есть нюансы, например A implements B — при использовании xcache B все равно будет подгружен через __autoload()
Хотя на самом деле на этапе выполнения опкода виртуальной машиной интерфейсы уже не нужны.
Но есть нюансы, например A implements B — при использовании xcache B все равно будет подгружен через __autoload()
Хотя на самом деле на этапе выполнения опкода виртуальной машиной интерфейсы уже не нужны.
В том то и дело. Мне вообще не понятны эти утверждения насчет скоростей. Боюсь, что если копать, то окажется что это не аргумент основной, а основной другой.
как показывает опыт интерфейсы незаменимы при стандартизации интерфейсов. Таким образом вы готовите почву для рефакторинга и проведя его вы как правило получите выигрыш в скорости намного больший чем экономя на них. я не говорю даже о устойчивости кода, о наглядности (засчет выделения абстракций), о скорости нахождения лог.ошибок.
как показывает опыт интерфейсы незаменимы при стандартизации интерфейсов. Таким образом вы готовите почву для рефакторинга и проведя его вы как правило получите выигрыш в скорости намного больший чем экономя на них. я не говорю даже о устойчивости кода, о наглядности (засчет выделения абстракций), о скорости нахождения лог.ошибок.
на этапе выполнения опкода виртуальной машиной интерфейсы уже не нужны.
нужны, пример:
intarface B…
if ($obj instanceof B){} — заранее не известно что будет жить в $obj
поэтому я и писал
это в основном проверки на этапе компиляции и редко на этапе исполнения.
Теоретически для каждого класса можно хранить массив всех его типов, этот массив четко известен на этапе создания опкода.
То есть для obj мы знаем основной класс, дальше можем запросить этот массив.
Если один из заявленных интерфейсов не реализован — об этом тоже четко известно на этапе создания опкода.
То есть в теории интерфейсы все-таки не нужны на этапе выполнения.
Конкретная практическая реализация — это конечно немного другое…
То есть для obj мы знаем основной класс, дальше можем запросить этот массив.
Если один из заявленных интерфейсов не реализован — об этом тоже четко известно на этапе создания опкода.
То есть в теории интерфейсы все-таки не нужны на этапе выполнения.
Конкретная практическая реализация — это конечно немного другое…
да, вы правы, в таблице наследования класса все есть, учитывая что на нее ссылается каждый экземпляр, то действительно на этапе исполнения нет наклодных расходов вовсе. Что-то я протормозил. Спасибо.
да, вы правы, в таблице наследования класса все есть, учитывая что на нее ссылается каждый экземпляр, то действительно на этапе исполнения нет наклодных расходов вовсе. Что-то я протормозил. Спасибо.
а теперь давайте вспомним где в пхп у нас идет компиляция…
Все-таки в общих чертах вы оказались правы :)
По-моему одно из самых важных нововведений PHP5
А как же! Ждали.. ждали.. и не использовать? :)
ага, согласен, вот только результаты пока 50/50
И еще топик минусуют :(
И еще топик минусуют :(
Да, использую.
Начал использовать PHP (да и вообще, программировать) сразу с пятой версии. Интерфейсы - мегаполезная штука, не представляю, как раньше люди без них жили =) Хотя, вообще, можно эмулировать..
Начал использовать PHP (да и вообще, программировать) сразу с пятой версии. Интерфейсы - мегаполезная штука, не представляю, как раньше люди без них жили =) Хотя, вообще, можно эмулировать..
даже когда не хочу использовать, не получается :) поэтому использую всегда
Покажите же уже пример, который показывает, как интерфейсы жить помогают…
А насчёт быдлокодеров, то они теперь наоборот стараются всё настолько заобъектить, что в итоге эту кашу переварить становится просто невозможно ;)
А насчёт быдлокодеров, то они теперь наоборот стараются всё настолько заобъектить, что в итоге эту кашу переварить становится просто невозможно ;)
Поддерживаю, покажите (или расскажите) ... я кроме имплементации SPL-интерфейсов не нашел пока ни одного удобного (оправданного) применения, как ни старался
например вы очень облегчите жизнь использующим ваши классы разработчикам, если на видном месте опишете интерфейс с некоторыми комментариями...
т.е. я вижу пользу интерфейсов:
т.е. я вижу пользу интерфейсов:
- собственно в создании интерфейсов между объектами
- в самодокументировании и самоконтроле
- в spl-интерфейсах, таки повторюсь
Качаем Zend Framework, ищем по слову interface, фтыкаем.
Вы как бы говорите нам о том, что сами не в теме.
Зря вы так. У Zend Framework действительно стоит многому поучиться, в том числе и применению ООП на деле.
Интерфейсы там применены к месту.
Интерфейсы там применены к месту.
Подписываюсь под каждым словом
Скачал я ZF/ Вы считаете if ($object instanceof IInterface) { - применением интерфейсов к месту? Ээ...
Посмотрите цепочки фильтров и валидаторов например
(Zend_Filter и Zend_Validate). Фильтры и валидаторы реализуют интерфейсы (implements), оставляя возможность наследования.
/**
* Adds a filter to the end of the chain
*
* @param Zend_Filter_Interface $filter
* @return Zend_Filter Provides a fluent interface
*/
public function addFilter(Zend_Filter_Interface $filter)
{
$this->_filters[] = $filter;
return $this;
}
Это первое, что пришло в голову, на самом деле там есть более удачные примеры.
(Zend_Filter и Zend_Validate). Фильтры и валидаторы реализуют интерфейсы (implements), оставляя возможность наследования.
/**
* Adds a filter to the end of the chain
*
* @param Zend_Filter_Interface $filter
* @return Zend_Filter Provides a fluent interface
*/
public function addFilter(Zend_Filter_Interface $filter)
{
$this->_filters[] = $filter;
return $this;
}
Это первое, что пришло в голову, на самом деле там есть более удачные примеры.
Мне ничего не мешает написать так, и я нисколько не обломаюсь:
public function addFilter($filter)
{
$this->_filters[] = $filter;
return $this;
}
public function addFilter($filter)
{
$this->_filters[] = $filter;
return $this;
}
В больших сложных проектах с несколькими программистами такой код - зло (или детство:).
Почему? Вы сейчас фактически говорите, что все языки без типизации - зло, или что все объекты должны ОБЯЗАНЫ реализовывать интерфейсы.
Ну ведь мы сейчас только про PHP говорим.
Если метод объявлен с type hinting - одного взгляда на него достаточно, чтобы понять, что он примерно делает.
Хороший код сам ведет программиста, не давая ошибиться.
Если метод объявлен с type hinting - одного взгляда на него достаточно, чтобы понять, что он примерно делает.
Хороший код сам ведет программиста, не давая ошибиться.
Я так понимаю что вы за строгую типизацию в PHP? Мне кажется что проектная документация - гораздо лучшее решение проблемы (нежели интерфейсы) для проектов с большим количеством участников. Я исхожу из собственного опыта.
Да, я за максимально строгую типизацию и строгость кода.
Типизация не мешает проектной документации, и то и другое - хорошо.
Типизация не мешает проектной документации, и то и другое - хорошо.
Тогда наш с вами спор выходит за рамки обсуждения интерфейсов в php. Это уже будет "Строгая типизация: за и против".
У меня вопрос, почему тогда вы работаете с PHP, а не скажем, с Java?
У меня вопрос, почему тогда вы работаете с PHP, а не скажем, с Java?
Не дописал. С позиции строгой типизации, я с вами полностью согласен. Для этого интерфейсы очень удобны. Но это не технологическое их использование, а организационное. А я пытаюсь найти разумное технологическое использование. Его как раз в PHP то и нет. И как раз в ввиду отсутсвия ОБЯЗАТЕЛЬНОЙ строгой типизации.
Да, возможно это больше организационная штука. Возможно это скорее для программиста, чем для программы. Но без таких вещей в крупных проектах не так комфортно. Лучший код рождается там, где комфортно программисту.
А по поводу отсутствия ОБЯЗАТЕЛЬНОЙ типизации - вам ничто не мешает сказать "в моей программе типизация ОБЯЗАТЕЛЬНА" и писать максимально строгий код.
Кстати, тайпхинтинг в параметрах функции обеспечивает автокомплишн с выводом встроенной документации (например в Zend_Studio), что в больших проектах с сотнями классов и тысячами методов очень сильно помогает.
А по поводу отсутствия ОБЯЗАТЕЛЬНОЙ типизации - вам ничто не мешает сказать "в моей программе типизация ОБЯЗАТЕЛЬНА" и писать максимально строгий код.
Кстати, тайпхинтинг в параметрах функции обеспечивает автокомплишн с выводом встроенной документации (например в Zend_Studio), что в больших проектах с сотнями классов и тысячами методов очень сильно помогает.
Зато обломается и будет громко матерится человек которым этим кодом воспользуется.
Интерфейсы раскрутились на полную в COM-архитектурах, когда есть библиотека черный-ящик, которая содержит в себе объекты, доступ к которым осуществляется через интерфейсы этих объектов. И если вы считаете что основная суть интерфейсов в instanceof то преречитайте этот коммент еще раз и изучите историю предмета.
Без строгой типизации и дефолтного error_reporting(E_ALL) смысла в их использовании нет.
Интерефейс это один из результатов проектирования, проектирование это основаная часть программирования. Интерфэйсы делают код более прозрачным, логичным и понятным, и являютса правилами и направлением для логики. Есле вы пишите маленькие "скриптики" или даже "классики" то скорее всего вам они необъязательны. Но есле вдруг вы взялись за огромную работу которая требует гибкости кода, его возможной разширяемости и масштабируемости то интерфэйсы это то что вам скорее всего требуетса знать.
Самый распространённый пример применения интерфэйса это абстракция базы данных. Давайте представим для чего...?! В PHP есть полно расширений для работы с базами данных, для MySQL их не менее трех msql, msqli, pdo_msql и т.д. А ведь по сути нам всего нужно выбрать, обновить, вставить, удалить... что собственно говоря и являетса базовым интерфэйсом. Мы отделяем то что нам необходимо от того как это реализовано. Нам не надо знать как это реализовано мы знаем как это работает, а сама реализация может менятса десятки раз.
Советую почитать книжку PHP 5 Power Programming там очень просто и понятно всё написано.
http://www.informit.com/content/images/013147149X/downloads/013147149X_book.pdf
Самый распространённый пример применения интерфэйса это абстракция базы данных. Давайте представим для чего...?! В PHP есть полно расширений для работы с базами данных, для MySQL их не менее трех msql, msqli, pdo_msql и т.д. А ведь по сути нам всего нужно выбрать, обновить, вставить, удалить... что собственно говоря и являетса базовым интерфэйсом. Мы отделяем то что нам необходимо от того как это реализовано. Нам не надо знать как это реализовано мы знаем как это работает, а сама реализация может менятса десятки раз.
Советую почитать книжку PHP 5 Power Programming там очень просто и понятно всё написано.
http://www.informit.com/content/images/013147149X/downloads/013147149X_book.pdf
Для этого не интерфейс нужен, а базовый абстрактный класс. Интерфейсы нужны для того что я выше в комменте написал.
Хорошо, допустим такой пример. Абстрагируем кеш. В данной ситуации от вашего абстрактного класса ни останется ни единого конкретного метода, одни абстрактные. В принципе это всё равно можно сделать абстрактным классом, но тогда теряется возможность наследовать в классе-реализаторе ещё какой-то класс.
Почему все путают интерфейсы с наследованием? Интерфейс нам говорит, что мы обязаны реализовать в классе все методы. Это как памятка. Типа: "Программер, не забудь реализовать это, это и это, иначе случится что-то плохое." Так что интерфейсы не дают нам возможности наследоваться от еще какого-то класса. И в итоге в ракурсе PHP вообще нам ничего не дают.
А почему мы не можем наследоваца от какого-нибудь класса и выполнить все требования интерфейса?
Ну так. Допустим мы реализуем кеш через Memcache. Класс-аксессор при этом принимает в конструкторе параметр типа CacheSorage.
Тогда мы создаём свой класс так:
class MemCacheStorage extends Memcache implemens CacheStorage.
Вы правы — интерфейсы не дают ничего нового, всё что они могут — ограничить нас в количестве ошибок, не более того.
Тогда мы создаём свой класс так:
class MemCacheStorage extends Memcache implemens CacheStorage.
Вы правы — интерфейсы не дают ничего нового, всё что они могут — ограничить нас в количестве ошибок, не более того.
Интерфэйсы и Абстрактные классы в PHP похожи, но это не одно и тоже. Какже например instanceof ??? И вообще абстрактные классы пойдее могут определять тело методов(в PHP немогут) а интерфэйсы нет.
Оторвитесь от книжек, определений и прочей теории. Абстрагируйтесь и поразмыслите головой какая польза от этих самых интерфейсов в PHP?
А какая польза от комментариев? Тоже, непосредственно, на исполнение программы особенно не влияют.
Вот я и говорю, что кроме SPL, реального применения почти нет
знаешь, код можно и в столбик писать. И, я тебя даже удивлю, - он будет работать быстрее чем четко струткурированный по абстракциям и слоям объектный монстр. Но вот потребуется тебе что-то с ним сделать, ты жопу порвешь и будешь мечатать, что вот копипаст, который сделал ты сейчас - ты правильно подправил и ты не словишь еще с десяток ошибок.
Вы свою манеру изложения, ака "я самый умный" оставьте пожалуйста при себе.
Без вас знаю где и зачем используются интерфейсы, и как они "упрощают" сопровождение кода.
Бьюсь об заклад, что там, где вы их используете, у вас постоянно выскакивает "instanceof". Так? А о чем это говорит? А об этом читайте в книжках Мартина Фаулера
Без вас знаю где и зачем используются интерфейсы, и как они "упрощают" сопровождение кода.
Бьюсь об заклад, что там, где вы их используете, у вас постоянно выскакивает "instanceof". Так? А о чем это говорит? А об этом читайте в книжках Мартина Фаулера
Польза хотябы в том чтобы научить PHP програмистов лучше мыслить в ООП а это значит на всех совремменных языках програмирования. Раскажи лучше какой вред?
в js и питоне нет интерфейсов :)
в асме классов нет, хороший язык получился. Может быть они ваще ненужны7
Javscript это прежде всего СКРИПТ язык, да мощный скрипт язык, да с потдержкой ООП а точнее там всё что ты создаёш обьект, но он нетребует потдержки ООП такого уровня, во всяком случае раньше не требовал. В Pythone родной потдержки интерфэйсов нету, аля кейворда interface зато это не мешает их реализовывать в виде классов посмотри хотябы на интерфэйсы Zope.
Если интерфейсов не существует их изобретают. В питоне изобрели протоколы. Имхо, всё-таки немного более громоздкое решение, чем интерефейсы. Да и просто интерфейсы как-то привычнее.
Вред от наличия интерфесов в PHP есть - ими пользуются и делают это неправильно, лишь усложняя сопровождение
Для PHP — расширенный тайпхинтинг. И это неплохо, заметьте.
Применяю ООП, интерфейсы не использую. Насколько я понимаю, интерфейсы помогают:
1) более тщательно следить за полиморфизмом (все полиморфные классы реализуют один и тот же интерфейс)
2) "документировать" предназначение класса (типа он наследует iPrintable, значит, оно может печатать)
3) наверняка я еще десяток пунктов не знаю.
Вообще, полагаю, интерфейсы бесполезны, когда они идут в комплекте с единственным классом. То есть интерфейс может быть полезен только тогда, когда описывается взаимодействие классов или их взаимное "положение" в системе.
Будьте добры, подскажите пожалуйста действительно удобное и полезное применение интерфейсов в РНР.
1) более тщательно следить за полиморфизмом (все полиморфные классы реализуют один и тот же интерфейс)
2) "документировать" предназначение класса (типа он наследует iPrintable, значит, оно может печатать)
3) наверняка я еще десяток пунктов не знаю.
Вообще, полагаю, интерфейсы бесполезны, когда они идут в комплекте с единственным классом. То есть интерфейс может быть полезен только тогда, когда описывается взаимодействие классов или их взаимное "положение" в системе.
Будьте добры, подскажите пожалуйста действительно удобное и полезное применение интерфейсов в РНР.
Повторю свой пример с кешем. Есть управляющая функция, которая принимает объекты, реализующие интерфейс Cacheable. Такими являются MemCacheStorage, ApcCacheStorage, FileCacheStorage, DbCacheStorage.
Какой из них будет применён решает юзер в конфиге, функции в принципе пофиг, но ровно до момента когда нужный класс не инициализировался или кто-то попробовал подать на вход чужеродный класс. Тут-то и выпадет ошибка.
Какой из них будет применён решает юзер в конфиге, функции в принципе пофиг, но ровно до момента когда нужный класс не инициализировался или кто-то попробовал подать на вход чужеродный класс. Тут-то и выпадет ошибка.
Млин, извиняюсь, попутал. Интерфейс назывался CacheStorage. Сacheable — интерфейс для кешируемых объектов.
Иначе говоря, это п.1: помощь в реализации полиморфизма, верно?
Да, если я правильно вас понял. Следить в данной ситуации это очень абстрактное понятие. Уточню для данной ситуации: один разработчик следит за собой и другими на этапе выполнения скрипта. Раньше увидеть ошибку в данной ситуации проблемотично.
Вы же знаете, наверное, что такое Type Hinting?
Вы же знаете, наверное, что такое Type Hinting?
*«проблематично», извиняюсь
>Вы же знаете, наверное, что такое Type Hinting?
нет. *стыдно* Пошел изучать тему.
нет. *стыдно* Пошел изучать тему.
А, блин. Это всего лишь указание типа объекта, передаваемого в параметрах функции? :)
Знаете-знаете, я думаю, просто название такое не слышали. =)
В любом языке вы пишите список аргументов и указываете их типы «void a(String a)», типа такого. Если какой-то из типов при вызове функции не совпал, то выпадает ошибка, либо компилятора, либо интерпретатора.
PHP же к типам так не придирается, ему число в строку преобразовать — раз плюнуть, поэтому в PHP убрали элементарные типы в качестве ограничений для параметров — если что, мол, типы к нужным сами приведём.
Поэтому такой код:
в PHP неверен.
То что оставили нам это возможность указывать свои собственные типы в качестве желаемых, да ещё array, кажется и называется это всё дело «Type Hinting», т.е. возможность «подсказать тип».
Кстати, с помощью одного костыля можно реализовать и ограничения на простые типы, но я это у себя убрал вскоре, так как процентов на 5% скорость работы уменьшалась.
В любом языке вы пишите список аргументов и указываете их типы «void a(String a)», типа такого. Если какой-то из типов при вызове функции не совпал, то выпадает ошибка, либо компилятора, либо интерпретатора.
PHP же к типам так не придирается, ему число в строку преобразовать — раз плюнуть, поэтому в PHP убрали элементарные типы в качестве ограничений для параметров — если что, мол, типы к нужным сами приведём.
Поэтому такой код:
function a(string $x){}
в PHP неверен.
То что оставили нам это возможность указывать свои собственные типы в качестве желаемых, да ещё array, кажется и называется это всё дело «Type Hinting», т.е. возможность «подсказать тип».
Кстати, с помощью одного костыля можно реализовать и ограничения на простые типы, но я это у себя убрал вскоре, так как процентов на 5% скорость работы уменьшалась.
Вам же уже сказали, что эту же задачу можно также решить при помощи абстрактного класса
Конечно можно, к примеру в том же си вообще нет интерфейсов, а их роль выполняют абстрактные классы. Но в си есть множественное наслодовение...
но в приведенном примере множественное наследование не требуется
Требуется. К примеру класс DbCacheStorage наследуюется от класса DB, который хранит несколько нужных утилитарных функций и сам наследуется от PDO.
Оспорю, DbCacheStorage должен наследоваться от AbstractCacheStorage и инкапсулировать DB
логически: хранилище кэша это не расширенное новыми методами подключение к СУБД
логически: хранилище кэша это не расширенное новыми методами подключение к СУБД
Я в принципе согласен с вами, но где-то в глубине души я разделяю внешние стандарты, которые надо блюсти строго и внутренние, которые можно подогнать под своё удобство и в данной ситуации поддаюсь искушению наследоваться от Memcache, PDO, etc. потому, что это удобно.
Это какие такие стандарты?
присмотритесь к структуре: ваш DbCacheStorage органичен использованием лишь одного конкретного типа СУБД. Тоже самое про наследование от PDO.
Если уж DB, то AbstractDB и набор потомков для каждого типа DB.
Если уж CacheStorage, то AbstractCacheStorage и набор потомков для разных типов хранилищь
Если уж DBCacheStorage, то параметризованный AbstractDB (т.е. умеющий работать с любой DB)
присмотритесь к структуре: ваш DbCacheStorage органичен использованием лишь одного конкретного типа СУБД. Тоже самое про наследование от PDO.
Если уж DB, то AbstractDB и набор потомков для каждого типа DB.
Если уж CacheStorage, то AbstractCacheStorage и набор потомков для разных типов хранилищь
Если уж DBCacheStorage, то параметризованный AbstractDB (т.е. умеющий работать с любой DB)
DB итак абстрактным является;
CacheStorage тем более интерфейс;
DBCacheStorage суть обвеска DB новыми функциями;
конструктор DB в качестве аргумента кушает тип DB, так что он с любой базой работает по умолчанию;
CacheStorage тем более интерфейс;
DBCacheStorage суть обвеска DB новыми функциями;
конструктор DB в качестве аргумента кушает тип DB, так что он с любой базой работает по умолчанию;
а не получается ли у вас 2 подключения к DB? одно от CacheStorage, а второе от основного DB, используемого в приложении?
он не выносной, он родительский, он же соединение и держит
тогда непонятно зачем вам вообще интерфейс DbCacheStorage, если фактически применить другой объект (например ApcCacheStorage), реализующий этот интерфейс нельзя ибо тогда приложение останется без коннекта к СУБД
скоро вы меня запутаете окончательно)
ещё раз:
interface CacheStorage
class DbCacheStorage extends DB implements CacheStorage
class MemCacheStorage extends Memcache implements CacheStorage
про коннект к ДБ поясню — на данный момент используется SQLite, так что коннектов и правда много, но все они к разным БД.
ещё раз:
interface CacheStorage
class DbCacheStorage extends DB implements CacheStorage
class MemCacheStorage extends Memcache implements CacheStorage
про коннект к ДБ поясню — на данный момент используется SQLite, так что коннектов и правда много, но все они к разным БД.
Резюмируя:
В комментариях налицо недопонимание между людьми. Те, кто говорит об отсутствии необходимости пользоваться интерфейсами (в том числе я), говорят не о интерфейсах, как часть парадигмы ООП, а скорее о ключевых словах "implements" и "interface" в PHP5.
Интерфейс, как структурная составляющаяя, есть у любого класса, как неотъемлемая его часть.
Быть может имеет место утверждение: Интерфейсами пользуются все, но не все об этом догадываются?
В комментариях налицо недопонимание между людьми. Те, кто говорит об отсутствии необходимости пользоваться интерфейсами (в том числе я), говорят не о интерфейсах, как часть парадигмы ООП, а скорее о ключевых словах "implements" и "interface" в PHP5.
Интерфейс, как структурная составляющаяя, есть у любого класса, как неотъемлемая его часть.
Быть может имеет место утверждение: Интерфейсами пользуются все, но не все об этом догадываются?
*снимая маску серьёзности*
Если не секрет, почему вас так тянет на абстрактные классы? =)
Если не секрет, почему вас так тянет на абстрактные классы? =)
Я бы сформулировал так:
Меня не тянет к ключевому слову interface.
А вдруг я затра обнаружу у всех своих "реализаторов" интерфейса IPrintable, один и тотже метод "::print()" - мне станет жутко неуютно
Меня не тянет к ключевому слову interface.
А вдруг я затра обнаружу у всех своих "реализаторов" интерфейса IPrintable, один и тотже метод "::print()" - мне станет жутко неуютно
Так как примера я не увидел — то наведу его сам. Вот собственно он.
И вопрос не к месту. Интерфейс нужно использовать там где нужно. Не только в PHP.
И вопрос не к месту. Интерфейс нужно использовать там где нужно. Не только в PHP.
>>> import this
The Zen of Python, by Tim Peters
...
There should be one — and preferably only one — obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
...
Об этом применении уже было сказано:
http://habrahabr.ru/blog/php/38961.html#…
http://habrahabr.ru/blog/php/38961.html#…
это не совсем то, о чем здесь идет дисскусия. Это скорее утилитарное применение, слабо связанное с ООП
http://habrahabr.ru/blog/php/38961.html#…
http://habrahabr.ru/blog/php/38961.html#…
это не совсем то, о чем здесь идет дисскусия. Это скорее утилитарное применение, слабо связанное с ООП
SPL - классический пример. позволяет вашим объектам обрабатываться встроеным функционалом PHP. Это COM.
Думаю что каждый уважающий себя и окружающих программист должен использовать interface для того чтобы доставить себе и другим удовольствие кодинга. Понятное дело что это не просто и можно итка без интерфейсов наклепать, но если вы пишите серьезный проект с которым будут работать другие программисты, то им не придется вникать 2 года на изучение того когда что вы написали, я образно, а качественно продолжить работу. Это как пример. А так самому должно быть приятно смотреть на свой прозрачный код. Да и считаю что код хорош и прозрачен тогда когда без доки понятно что и как ИМХО , ну это высший пилотаж )))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используете ли вы интерфейсы (… implements...) в PHP5 (Навеяно предыдущим опросом)