вы не внимательный читатель. я не сравниваю (а что нужно сравнительный анализ сделать технологий и решений?) я рассказываю что на эту тему всегда есть люди, готовые поспорить и привожу топ причин для споров.
пожалуй нужно пояснить почему тут не обойтись просто наследованием от абстрактного класса. Рассмотрим задачку кеширования: например у нас есть Observer который следит за состоянием кеша (задачи прегенерации, задачи логирования и т.д.) и много маленьких разнопрофильных клиентов. Кто-то из клиентов, например, меняет состояние кеша и просит обсервер всех уведомить, что кеш нужно сбросить.
Понятно, что все клиенты отвечают за разные части системы и потому держать в основании дерева их классов ObserverClient не целесообразно.
А так например у нас есть готовый модуль (class A) и мы говорим: теперь эта сущность (наш модуль) тоже научилась работать c нашим сервером кеша (class ACached extends A implements CacheClient)
простите, что примеры немного искуственными кажутся, просто полностью раскрывать задачи занятие не для часу ночи.
Но суть такова: интерфейсы необходимы для стандартизации, а ее нельзя достичь простым наследованием т.к. объекты по своей природе не наследуются от одного родителя (например разнопрофильные сторониие библиотеки).
спасибо, что смогли тут написать. Очень трудно всю информацию подбить в одно место, а не размазывать по топикам.
ДУПА дал ответ. habrahabr.ru/blogs/php/45651/#comment_1159897
Но лично я считаю что нужно использовать квик (сейчас сайт не доступен, но можно получить копию у меня (пишите в личку)).
а вообще использование таких вложенных структур осуждается, хотя я лично использую
да, использую, особенно когда в команде работаю с 2-мя и более программистами, при помощи интерфейсов очень просто стандартизировать поведение. Ну например (вымышленный) сделай мне шаблонизатор который реализует интерфейс
implements Templater{
public function assign($name, $value);
}
ну или есть у вас в системе Observer, вам скармливают объект-слушающий, а у вас стандартизирован вызов:
Observer::add = public function(ObserverClient $obj);
в основном в таком контексте: тоесть для формализации ТЗ и интерфейса доступа.
В том то и дело. Мне вообще не понятны эти утверждения насчет скоростей. Боюсь, что если копать, то окажется что это не аргумент основной, а основной другой.
как показывает опыт интерфейсы незаменимы при стандартизации интерфейсов. Таким образом вы готовите почву для рефакторинга и проведя его вы как правило получите выигрыш в скорости намного больший чем экономя на них. я не говорю даже о устойчивости кода, о наглядности (засчет выделения абстракций), о скорости нахождения лог.ошибок.
неправду говорите, особено в слове сильно. ибо интерфейсы — это в основном проверки на этапе компиляции и редко на этапе исполнения. Нельзя ж так обманывать
обычно управляет контроллер, обрабатывает модель, выводит вьювер. то что у вас часть модели занята логикой вывода — это означает что сильная связь между элементами вьювера и модели. Попробуйте разбить эту логику на 2 сущности (я не призываю вас к шаблонизаторам, просто разбить), тогда вы получите разные сферы деятельности: деятельность направленная на обработку данных, деятельность направленная на отображение данных
Все что сказал автор суть верно в той или иной мере. Сам я ездил на конференции и видел как студент несет чушь полную, а потом встает умный дядечка и говорит этого не может быть потому-то например, а ему студен и говорит: а вот мой научрук мол написал статью — иди читай. Дядечка умный и воспитаный поэтому он и говорит: глупости ваш научрук написал, не строгие там все утверждения и доказательства, но спор он не продолжает потому что время пленарного доклада 15 минут. и статья публикуется с глупостями, с несуразностями, а потом в каждой такой статье есть ссылка на работу научрука и рейтинг научрука растет и он уже становится известным, даже несмотря на то что бесполезен его труд
выглядит красиво, корпус компактный, так что получилось весьма не дурно
особенно прикольно выглядят порты USB. Кстати интересно а джойстики подключить еще можно?
Понятно, что все клиенты отвечают за разные части системы и потому держать в основании дерева их классов ObserverClient не целесообразно.
А так например у нас есть готовый модуль (class A) и мы говорим: теперь эта сущность (наш модуль) тоже научилась работать c нашим сервером кеша (class ACached extends A implements CacheClient)
простите, что примеры немного искуственными кажутся, просто полностью раскрывать задачи занятие не для часу ночи.
Но суть такова: интерфейсы необходимы для стандартизации, а ее нельзя достичь простым наследованием т.к. объекты по своей природе не наследуются от одного родителя (например разнопрофильные сторониие библиотеки).
ДУПА дал ответ. habrahabr.ru/blogs/php/45651/#comment_1159897
Но лично я считаю что нужно использовать квик (сейчас сайт не доступен, но можно получить копию у меня (пишите в личку)).
а вообще использование таких вложенных структур осуждается, хотя я лично использую
implements Templater{
public function assign($name, $value);
}
ну или есть у вас в системе Observer, вам скармливают объект-слушающий, а у вас стандартизирован вызов:
Observer::add = public function(ObserverClient $obj);
в основном в таком контексте: тоесть для формализации ТЗ и интерфейса доступа.
как показывает опыт интерфейсы незаменимы при стандартизации интерфейсов. Таким образом вы готовите почву для рефакторинга и проведя его вы как правило получите выигрыш в скорости намного больший чем экономя на них. я не говорю даже о устойчивости кода, о наглядности (засчет выделения абстракций), о скорости нахождения лог.ошибок.
обычно управляет контроллер, обрабатывает модель, выводит вьювер. то что у вас часть модели занята логикой вывода — это означает что сильная связь между элементами вьювера и модели. Попробуйте разбить эту логику на 2 сущности (я не призываю вас к шаблонизаторам, просто разбить), тогда вы получите разные сферы деятельности: деятельность направленная на обработку данных, деятельность направленная на отображение данных
особенно прикольно выглядят порты USB. Кстати интересно а джойстики подключить еще можно?