Мы все живем в современном, быстро растущем и меняющемся мире. Новые современные технологии и методики разработки появляются с ужасающей скоростью. Не успеешь закончить какой то проект, как смотришь, уже появились решения, с помощью которых можно было все сделать проще и быстрее.
Сложность больших проектов в их неспособности быстро адаптироваться под все новое и современное. А надо ли? Этот вопрос всегда вызывает много споров и разногласий. В конечном итоге все сводится к тому, что особо не надо, но все равно приходится. Программист который отлично писал на PHP4, но забил на изучение PHP5, может сегодня остаться без работы. Хотя в проектах, которые он делал, фичи PHP5 по большому счету не нужны. Проект и так хорошо работал (и возможно работает) на PHP4.
Сейчас паттерны проектирования(design patterns) считаются хорошей практикой разработки. Это практика стала настолько хороша, что иногда программисты вставляют паттерны везде где только можно, не задумываясь, а нужны ли они тут вообще. Современный разработчик как правило знает несколько распространенных в практике паттернов (обычно это singleton, factory method, observer, decorator, возможно MVC).
На практике не всегда можно сходу "узнать" паттерн в коде приложения, т.к сам паттерн описывает некую архитектурную конструкцию приложения, но не ее реализацию в коде. Итак, хочу познакомить вас с несколькими паттернами проектирования, реализованными в битрикс
Небольшое отступление: вообще тема про паттерны в битрикс возникла случайно в моем разговоре с . Он хотел написать про это, но похоже я его немного опередил. Возможно ему будет что добавить от себя.
Observer(наблюдатель)
Мы все очень часто пользуемся обработчиками событий в битрикс, вещаем их на инфоблоки и другие объекты, так вот это очень похоже на observer. Классический observer немного более ограничен, т.к не имеет информации о том, какое событие произошло. Другой кандидат на эту должность это event dispatcher.
Singleton(одиночка)
В точности singleton в битрикс не реализован, но можно предположить, что глобальные переменные $APPLICATION и $DB это как раз прямые кандидаты в singleton.
MVC (Модель - представление - контроллер)
Мы все про него много знаем. Всем нам вдалбливали в голову, что при разработке web-приложений нужно обязательно следовать MVC. Да, я согласен . MVC в битрикс - это компоненты 2.0. Компонент - это контроллер, шаблон - представление, а модули - это модель.
Front controller (единая точка входа в приложение)
Это мой любимый паттерн. В битрикс его нет, но если предположить, что есть некий глобальный комплексный компонент для всего сайта, то его можно будет назвать Front controller.
Adapter
$DB это практически и есть адаптер. Мы подключаем конкретную реализацию для конкретной базы данных, при это все реализации имеют единый интерфейс для работы с базой.
Decorator
Компоненты 2.0 кроме MVC это еще и немножко декораторы. Мы можем изменить поведение компонента вне самого компонента, например в эпилоге компонента. Правда decorator предусматривает наличие двух объектов, а у нас компонент и эпилог объектами не является, но общее с decorator все равно есть.
Стоит добавить, что в битрикс не совсем очевидная реализация вышеперечисленных паттернов. Возможно некоторые другие паттерны я упустил из виду. Кстати компоненты 2.0, если верить мануалу битрикс, реализуют другой паттерн - Carrier Rider Mapper. Я сути этого паттерна не уловил, поэтому для меня это просто MVC.
Сложность больших проектов в их неспособности быстро адаптироваться под все новое и современное. А надо ли? Этот вопрос всегда вызывает много споров и разногласий. В конечном итоге все сводится к тому, что особо не надо, но все равно приходится. Программист который отлично писал на PHP4, но забил на изучение PHP5, может сегодня остаться без работы. Хотя в проектах, которые он делал, фичи PHP5 по большому счету не нужны. Проект и так хорошо работал (и возможно работает) на PHP4.
Сейчас паттерны проектирования(design patterns) считаются хорошей практикой разработки. Это практика стала настолько хороша, что иногда программисты вставляют паттерны везде где только можно, не задумываясь, а нужны ли они тут вообще. Современный разработчик как правило знает несколько распространенных в практике паттернов (обычно это singleton, factory method, observer, decorator, возможно MVC).
На практике не всегда можно сходу "узнать" паттерн в коде приложения, т.к сам паттерн описывает некую архитектурную конструкцию приложения, но не ее реализацию в коде. Итак, хочу познакомить вас с несколькими паттернами проектирования, реализованными в битрикс
Небольшое отступление: вообще тема про паттерны в битрикс возникла случайно в моем разговоре с . Он хотел написать про это, но похоже я его немного опередил. Возможно ему будет что добавить от себя.
Observer(наблюдатель)
Мы все очень часто пользуемся обработчиками событий в битрикс, вещаем их на инфоблоки и другие объекты, так вот это очень похоже на observer. Классический observer немного более ограничен, т.к не имеет информации о том, какое событие произошло. Другой кандидат на эту должность это event dispatcher.
Singleton(одиночка)
В точности singleton в битрикс не реализован, но можно предположить, что глобальные переменные $APPLICATION и $DB это как раз прямые кандидаты в singleton.
MVC (Модель - представление - контроллер)
Мы все про него много знаем
. Всем нам вдалбливали в голову, что при разработке web-приложений нужно обязательно следовать MVC. Да, я согласен . MVC в битрикс - это компоненты 2.0. Компонент - это контроллер, шаблон - представление, а модули - это модель.Front controller (единая точка входа в приложение)
Это мой любимый паттерн
. В битрикс его нет, но если предположить, что есть некий глобальный комплексный компонент для всего сайта, то его можно будет назвать Front controller.Adapter
$DB это практически и есть адаптер. Мы подключаем конкретную реализацию для конкретной базы данных, при это все реализации имеют единый интерфейс для работы с базой.
Decorator
Компоненты 2.0 кроме MVC это еще и немножко декораторы. Мы можем изменить поведение компонента вне самого компонента, например в эпилоге компонента. Правда decorator предусматривает наличие двух объектов, а у нас компонент и эпилог объектами не является, но общее с decorator все равно есть.
Стоит добавить, что в битрикс не совсем очевидная реализация вышеперечисленных паттернов. Возможно некоторые другие паттерны я упустил из виду. Кстати компоненты 2.0, если верить мануалу битрикс, реализуют другой паттерн - Carrier Rider Mapper. Я сути этого паттерна не уловил, поэтому для меня это просто MVC.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
