AOP, использование в PHP
- Автор темы Adelf
- Дата начала
Alexandre
PHPПенсионер
PHPAspect вроде как давно существует
http://code.google.com/p/phpaspect/ или http://code.google.com/p/apdt/
http://phpaspect.blogspot.com/
http://www.aophp.net/
я могу быть не прав, но мне кажется аспекты усложняют программирование.
http://code.google.com/p/phpaspect/ или http://code.google.com/p/apdt/
http://phpaspect.blogspot.com/
http://www.aophp.net/
я могу быть не прав, но мне кажется аспекты усложняют программирование.
Alexandre ну я может не разобрался, но у него в свн alpha 0.1 выложенная в январе 2007 и больше ничего. Неужели этой альфы всем достаточно оказалось, что больше ничего и не надо?
-~{}~ 13.11.09 13:47:
http://code.google.com/p/apdt/ - вот это вот не смотрел... погляжу.
-~{}~ 13.11.09 13:47:
http://code.google.com/p/apdt/ - вот это вот не смотрел... погляжу.
>> я могу быть не прав, но мне кажется аспекты усложняют программирование.
Вот примерно ради таких мыслей и создавалась тема
Я прочитал статью на AgileDev - мне понравилось, порыскал по инету - энтузиазма убавилось. Хотел тут спросить - возможно использовал кто.
Вот примерно ради таких мыслей и создавалась тема
Я прочитал статью на AgileDev - мне понравилось, порыскал по инету - энтузиазма убавилось. Хотел тут спросить - возможно использовал кто.
atv
Новичок
Я бы с удовольствием использовал бы, но... решений нормальных нету.
Пробовал использовать для этой цели расширение runkit, но к сожалению, в нём обнаружились баги, которые ограничивают его использование, а поддержка этого расширения уже давно не осуществляется.
Сейчас использую АОП совсем чуть-чуть, для логгирования выполнения запросов к БД. Очень удобно, если мне нужно посмотреть запросы, раскомментирую одну строчку кода, в которой применяется аспект, и всё. Потом опять закомментировал и никаких лишних действий. Не нужно расставлять в драйверах БД вызовы к классу логирования, не нужно добавлять логику дебаг/продакшн режима и т.д.
Тут в прошлом году проскакивала интересная идея, перехватывать обращения require_once() и расставлять в коде код АОП, но автор обиделся на критику, так и не доделал проект.
Пробовал использовать для этой цели расширение runkit, но к сожалению, в нём обнаружились баги, которые ограничивают его использование, а поддержка этого расширения уже давно не осуществляется.
Сейчас использую АОП совсем чуть-чуть, для логгирования выполнения запросов к БД. Очень удобно, если мне нужно посмотреть запросы, раскомментирую одну строчку кода, в которой применяется аспект, и всё. Потом опять закомментировал и никаких лишних действий. Не нужно расставлять в драйверах БД вызовы к классу логирования, не нужно добавлять логику дебаг/продакшн режима и т.д.
Тут в прошлом году проскакивала интересная идея, перехватывать обращения require_once() и расставлять в коде код АОП, но автор обиделся на критику, так и не доделал проект.
Alexandre
PHPПенсионер
все у нас так, а жаль... у меня у самого была идея пару лет назад сделать АОПешный экстеншен, но идея канула в лету... как впрочем и много других, не менее интересных. Мое мнение - АОП не должен влиять на производительность. Было решение с АОП предпроцессором, который генерит говно-код. Но, мне это как-то не очень воодушевило. А вообще - переход на аспекты - это уже иног угол зрения, иная парадигма.
atv
Новичок
а может runkit подправишь, и уже можно будет юзать АОП
Любая абстракция влияет на производительность. АОП можно включать и выключать прямо в рантайме.
Ну, у АОП тоже есть своя область применения, вне которой он неэффективен. Он не вытесняет ООП, а дополняет его.
Инициализация среды при каждом вызове вообще отрицательно сказывается и не только на АОП, т.е. АОП не больше других страдает от этого.
atv
Новичок
Не вижу проблем сделать расставление колбэков в autoload, сделали в оработчике автозагрузки require_once, и тут же расставили колбэки, потом этот класс станет доступным в приложении.
Интересно увидеть логгирование запросов к БД, решаемое через filter chain
Мля, отмазки на уровне фишера про ОРМ. Какая куча, где не видно??? Однотипный код, который содержится в одном месте, а не размазан по нескольким классам? Ну хоть бы, попробовал, чем чушь нести.
korchasa
LIMB infected
Легко реализуется через навешивание прокси на класс соединения. В чем проблема? о_ОАвтор оригинала: atv
Интересно увидеть логгирование запросов к БД, решаемое через filter chain
Он только в примерах однотипный. В реальной жизни к "повесим логгер на все, что начинается на Service" через некоторое время добавляется - "если только это не ServiceLogger" и "если в конструктор не передали password". А потом сидишь у думаешь почему обработчик таки повесился, как бы сделать кастомные логи, да в разные файлы.
Лучше скажи где это реально могло бы помочь. Ну только не любимые три примера.
whirlwind
TDD infected, paranoid
atv функции тоже можно содержать в одном месте, однако ни гибкости, ни читабельности по сравнению с ооп это не добавляет. В оценке любого инструмента я использую очень простой критерий: инструмент, который вносит в код соглашения - плохой, инструмент, который вносит в код требования - хороший. АОП позволяет писать основываясь на соглашениях, а не на требованиях, следовательно позволяет писать [зачеркнуто]более раздолбайский[/зачеркнуто] менее контролируемый код.
Если не понятно о чем я говорю, то объясняю на пальцах - соглашение, это когда мы снаружи договариваемся, что такие-то объекты должны работать так-то. А требование, это когда объект сам за себя говорит - мне для работы нужно то-то. Если разница все еще не понятна, то советую подналечь на правильный ооп, чем нести чушь.
Если не понятно о чем я говорю, то объясняю на пальцах - соглашение, это когда мы снаружи договариваемся, что такие-то объекты должны работать так-то. А требование, это когда объект сам за себя говорит - мне для работы нужно то-то. Если разница все еще не понятна, то советую подналечь на правильный ооп, чем нести чушь.