да, вы правы, в таблице наследования класса все есть, учитывая что на нее ссылается каждый экземпляр, то действительно на этапе исполнения нет наклодных расходов вовсе. Что-то я протормозил. Спасибо.
вы не внимательный читатель. я не сравниваю (а что нужно сравнительный анализ сделать технологий и решений?) я рассказываю что на эту тему всегда есть люди, готовые поспорить и привожу топ причин для споров.
пожалуй нужно пояснить почему тут не обойтись просто наследованием от абстрактного класса. Рассмотрим задачку кеширования: например у нас есть 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);
в основном в таком контексте: тоесть для формализации ТЗ и интерфейса доступа.
В том то и дело. Мне вообще не понятны эти утверждения насчет скоростей. Боюсь, что если копать, то окажется что это не аргумент основной, а основной другой.
как показывает опыт интерфейсы незаменимы при стандартизации интерфейсов. Таким образом вы готовите почву для рефакторинга и проведя его вы как правило получите выигрыш в скорости намного больший чем экономя на них. я не говорю даже о устойчивости кода, о наглядности (засчет выделения абстракций), о скорости нахождения лог.ошибок.
неправду говорите, особено в слове сильно. ибо интерфейсы — это в основном проверки на этапе компиляции и редко на этапе исполнения. Нельзя ж так обманывать
нужны, пример:
intarface B…
if ($obj instanceof B){} — заранее не известно что будет жить в $obj
поэтому я и писал
Понятно, что все клиенты отвечают за разные части системы и потому держать в основании дерева их классов 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);
в основном в таком контексте: тоесть для формализации ТЗ и интерфейса доступа.
как показывает опыт интерфейсы незаменимы при стандартизации интерфейсов. Таким образом вы готовите почву для рефакторинга и проведя его вы как правило получите выигрыш в скорости намного больший чем экономя на них. я не говорю даже о устойчивости кода, о наглядности (засчет выделения абстракций), о скорости нахождения лог.ошибок.