В последннее время меня все чаще посещают мысли что паттерн observer(наблюдатель) - на самом деле является большим злом для архитектуры большинства систем. Если смотреть на него с теоретической точки зрения - одни плюсы. Взять хотябы его реализацию в магенте: там практически вся архитектура подключаемых модулей на этом паттерне построена. Нужно тебе выполнять какое-то действие при регистрации клиента - повесил обработчик на это событие и можеш быть(теоретически!) быть уверенным что тебя вызовут когда нужно. Можно фактически внедрятся в ядро системы и изменять ее поведение не меняя физически ни одного файла. Процесс установки модулей, который в других e-commerce системах зачастую наполнен шаманством с примением patch/diff и обязательным просмотром всех сделанных измений в магенте сводится к простому распаковыванию файлов в нужные места. Но за гибкость приходится платить.
Когда дело доходит до практического применения это же преимущество становится и большим недостатком:
1. Когда ты видеш вызов диспетчера какого-то события - тебе довольно трудно понять что действительно произойдет в этом месте кода. Никакая, даже самая умная IDE не сможет найти тебе те обработчики которые будут вызваны в этот момент. Тебе приходится самому искать их с помощью grep.
2. Вот нашел ты эти обработчики, а дальше что ? в общем случае ты не имеешь понятия в каком порядке они будут вызваны. И будут ли вызваны вообще.
3. Пол беды если эти обработчики написаны хорошими программистами. В этом случае ты можеш расчитывать что они не будут изменять ничего кроме тех объектов которые были переданы им вместе с событием. Но на практике часто случается что во время исполнения этих обработчиков меняется глобальное состояние систмы - либо явно через изменение каких -либо глобальных объектов либо неявно - через обращение к методам какого-нибуть синглтона. В результате мы получаем кучу side-эффектов. По сути ты вообще не знаешь что ждать после вызова диспетчера события.
В общем я склоняюсь ко мнению что при разработке архитектуры систем не предназначенных для коробочной продажи, использования этого паттерна лучше избежать.
Когда дело доходит до практического применения это же преимущество становится и большим недостатком:
1. Когда ты видеш вызов диспетчера какого-то события - тебе довольно трудно понять что действительно произойдет в этом месте кода. Никакая, даже самая умная IDE не сможет найти тебе те обработчики которые будут вызваны в этот момент. Тебе приходится самому искать их с помощью grep.
2. Вот нашел ты эти обработчики, а дальше что ? в общем случае ты не имеешь понятия в каком порядке они будут вызваны. И будут ли вызваны вообще.
3. Пол беды если эти обработчики написаны хорошими программистами. В этом случае ты можеш расчитывать что они не будут изменять ничего кроме тех объектов которые были переданы им вместе с событием. Но на практике часто случается что во время исполнения этих обработчиков меняется глобальное состояние систмы - либо явно через изменение каких -либо глобальных объектов либо неявно - через обращение к методам какого-нибуть синглтона. В результате мы получаем кучу side-эффектов. По сути ты вообще не знаешь что ждать после вызова диспетчера события.
В общем я склоняюсь ко мнению что при разработке архитектуры систем не предназначенных для коробочной продажи, использования этого паттерна лучше избежать.
Комментариев нет:
Отправить комментарий