Битрикс: пытаемся разобраться. Часть 2: Идеология и архитектура платформы 1с-Битрикс. ООП, ORM, Паттерны проектирования, MVC

Это вторая из трех статей про техническую, архитектурную и бизнес-составляющую системы 1С-Битрикс.
Статья ставит целью разобраться в колоссальном клубке вопросов, связанном с этой системой.
Начало:
Часть 1: Устройство и технические свойства платформы
Тут говорим об архитектуре.

Идеология и архитектура платформы

1.    Где ООП? Это структурный код, ООП и не пахнет.

Суть.
ООП вообще стало чем-то вроде священной коровы, эдакой волшебной мантрой. Все что с большим количеством классов, интерфейсов и наследований - автоматически круто и профессионально, а если ты пишешь структурный код -- тебе стыд и порицание. А за goto в коде сразу сажают на кол.
Знаете как в советских учениках было? Первобытный строй - Рабовладение - Феодализм - Капитализм - Социализм / Коммунизм. Типа линейное развитие. Чем дальше, тем круче. И все однозначно.
Вот не так все. И в ПО не так.
Попробуем порассуждать с позиции практичности. Что дает ООП и что — структурный код.
Для каких задач нужен объектно-ориентированный подход?
Он нужен для приложений со сложной бизнес-логикой, с перекрестными связями и зависимостями, с командной разработкой. Расписал интерфейсы, от общего развивающегося предка унаследовал и кайфуешь. Творишь. Все четко.

В Битриксе ООП почти нет. Большой единой иерархии нет. Классы Битрикса это инструменты, служащие контейнером для логики и слабо связанные друг с другом.

+ (что в этом хорошего)
1. Есть мнение что ООП как универсальная технология проектирования и кодирования почти любого софта не идеальна. В ней не так все просто и прямо как хочется. ООП -- не идеальная модель реального мира.
2. ООП надо не везде. Есть мнение что ООП в вебе не надо. Слишком простые и мало развиваемые вещи делает рядовой разработчик. Он просто делает элемент, выводящий корзину заказа в дизайне сайта и с его особенностями в логике.
И не надо для этого описывать ее поведение объектной моделью. Надо просто взять и кастомизировать код запроса на API и код вывода на html.
3. Быстро учим. Не надо держать в голове иерархию. Не надо помнить тысячу штук и нюансов где что как сделано. Оно тут все. Просто и наглядно. И развиваемо в любую сторону.
4. ООП мало кто хорошо понимает. Есть мнение что тысячи хороших программистов не могут писать на ООП. Им ближе, понятнее, прозрачнее скрипты и структурное кодирование.
Цена ошибки в выборе базовой технологии очень высока. Дело в том, что если ООП-шник влезет в “структурный” проект, он все поймет и ничего не испортит. Если он совсем тупой, за счет слабой связности все легко вычистить.
Если же “структурный” по стилю мышления человек влезет в суровое ООП дерево, он чего-нибудь там так унаследует и переопределит для вашего проекта, что мало не будет.
Коротко говоря: больше задач малой кровью в ущерб академичности и стройности абстрактных структур.
5. Никто не мешает прикрутить к Битриксу с его недо-ООП вашу собственную модель. И будет вам счастье, если оно для вас в ООП.

-
1. Многих раздражает. Операция копирования вместо наследования, классы как контейнеры, а не абстракции, та самая слабая связность.
2. Копипаст. Если считать что хороший код тот, где нет копипаста и повторяющихся кусков логики, то в проектах на Битриксе (не в нем самом) код плохой.
3. Если вы сделали свою версию компонента, которая очень мало отличается от исходного, и хотите обновиться, сохранившаяся часть логики не будет обновлена. Было бы это наследование, не переопределенная часть логики сохранилась бы и обновлялась бы.
А так получается, что вы нажали зеленую кнопку в панели, все обновилось быстро, а ваши кастомизированные компоненты не получили новых фишек.

2.    MVC и паттерны проектирования.
Суть
Пресловутые паттерны, банда четырех, Мартин Фаулер и понты вокруг всего этого стали уже даже не символом профессионализма, а его протезом.
Можно подумать что до появления идеи паттернов, изложенной в нескольких книгах вообще никто ничего серьезного не программировал. Кнут, Дейкстра, прочие умные товарищи -- судя по мнению современного гика -- гнилой отстой.
Удивительно, как часто в студенческих или сразу-после-студенческих кругах всплывает эта тема: а в Битриксе есть паттерны? Как будто их наличие и четкое выделение в документации сразу делает его клевым софтом и снимает все вопросы.
Товарищи программисты, давайте отставим юношеский максимализм и разберемся.
Что такое паттерны? Это исчерпывающий список правильных действий?
Лирическое отступление: у девочек в 17 лет есть справочник умных мыслей, позаимствованный частью у мамы, частью у лучшей подруги. Вот у современного “крутого девелопера” такой справочник сформировала банда четырех и Мартин Фаулер.

Паттерн - это совет. Это эвристический прием типа “попробуй так, может получится хорошо”.
Паттернов много, они описаны весьма абстрактно. Более того, есть версии и вариации на тему паттернов для отдельных языков программирования и технологий. В первоисточниках неоднократно разными словами высказана мысль что слепое применение паттернов или увлечение ими до наработки собственной профессиональной зрелости, приносит больше вреда чем пользы.
Применение того или иного приема нужно выбирать по особенностям конкретной ситуации. Никто не сказал, что паттерн А лучше оригинального решения С.
Это не скрижали Моисея, это неглупая, модная и в некоторых случаях полезная хрень, как, скажем, UML, Agile и RUP. Вам она помогает? Вы нашли в этом много полезного для своего уровня профессионального развития? Это прекрасно, но не надо быть наивными и считать что только так и можно писать.
Итак. Паттерны -- не самоцель.
Честно говоря, я бы вообще не обсуждал качество системы с точки зрения применения или не-применения конкретных паттернов, описанных в конкретных книгах.
Но в Битриксе паттерны проектирования безусловно используются.

+
Разумеется, так как Битрикс пишут множество нормальных и профессиональных программистов, в нем много случаев применения так нужных фанатикам паттернов. Так же как таких случаев применения паттернов полно в любой умной большой программе.
В Интернете есть ряд интереснейших дискуссий на эту тему между разработчиками, внедренцами и сторонними программистами. Прямых ссылок не будет, запрос “битрикс и паттерны проектирования” вас сразу приведет на эти страницы.
Документация изобилует указаниями на то, какой паттерн применен в том или ином месте. В качестве примера можно привести страницы про Компоненты 2.0.

-
Нет собственной прописанной философии, идеологии, централизованного духа системы. Проще всего его было бы сформулировать как раз в виде своих или модифицированных базовых паттернов.
Поскольку паттерны это религия, то каждый адепт считает себя носителем. И этот носитель утверждает в зависимости от опыта и степени адекватности что думает. А думают они совсем разное: кто-то практику применения ПП в Битриксе превозносит, кто-то поливает.
Если бы было понятно всем, а не только редким специалистам, ПОЧЕМУ оно так сделано, было бы лучше.

Вопрос паттернов дискуссионный, думаю в комментариях мое мнение будет дополнено.

Отдельно стоит поговорить про важный паттерн проектирования MVC.

MVC
+
Есть мнение (оно совпадает с официальным) что MVC в Битриксе есть. Посмотрите описание Компонентов 2.0.
Есть модель -- модули (я встречал версии, что это инфоблоки, админка, ядро), контроллер (компоненты, возможно файлы страниц сайта, urlrewrite), вид (шаблон или компонент целиком).
Если оно устраивает потребителя (программиста и его работодателя), то применение ПП надо считать адекватным.

-
Есть также мнение, что MVC в Битриксе нет.
Доводы в пользу этой мысли.
Модель размыта.
Контроллеров много.
View (если понимать его широко) находится в шаблоне и в самом компоненте и не так уж отделен от контроллера.
Не исключено, что этой мысли придерживаются люди, которые знакомы с конкретной реализацией MVC, например в Zend Framework.

3.    Где ORM?
Суть
ORM – красивая и интересная технология, при которой программист оперирует объектами своей модели, переходит по связям и выполняет действия на высоком уровне абстракции, а движок ORM переводит все это в язык запросов и отражает происходящее в хранилище данных.
Получается такой постоянный перевод, меппинг состояния памяти в БД и доступ к данным со всеми прелестями объектной модели.
Собственно, ORM это и есть object-relational mapping.
В php-версии Битрикса ORM нет.
Достоинством ORM является красота, краткость кода, все виды контроля, доступность объектов в памяти.
Недостатком ORM в ее классическом понимании являются повышенные требования к производительности и памяти. Это так или иначе решается ленивой загрузкой, ленивой генерацией instance’ов, внутренним кешированием, но тем не менее проблема налицо.
Ну и естественно, нужна нормальная объектная модель.

+ (что хорошего в том, что в Битриксе нет ORM)
Пример. Нужно получить список заказов человека.
С ORM имеем код типа theMan->Orders(), и список заказов в объектах.
В Битриксе вам не удастся получить список заказов в объектах, только в ассоциативном массиве, и не за один запрос. Сначала список ID, потом сами заказы.
theMan->Orders() генерирует массу объектов со всеми полями. Требуется много процессора и много памяти.
Стиль Битрикса позволяет получать ровно те данные, которые вам нужны.
Ну и разумеется, поскольку в Битриксе вообще мало что сделано объектами, а пользовательские сущности (отдельные новости, например) вообще объектами не являются, довольно странно говорить об их меппинге.
Если ваша задача требует ORM, ничего не мешает прикрутить к системе любую, работающую на php+mysql, например Doctrine.
Есть мнение, что применение ORM в сайтостроении (довольно простых проектах с точки зрения большого программирования) вообще неоправданно.

- (что плохого в отсутствии ORM)
Была бы ORM, которая бы умела экономить память, процессор и другие ресурсы, получала бы данные дозировано (сама) и в то же время позволяла красиво писать и быстро осваивалась – было бы отлично.
Такого нет в Битриксе.

Выводы по второй части.
ООП, ORM, Паттерны, MVC и прочие архитектурные вопросы сложны и рядовому пользователю и разработчику сложно о них судить.
Я не специалист в этом (не взялся бы проектировать CMS). Я постарался разобраться сам и аккумулировать в статье те доводы, которые нашел, понял и готов аргументировать.
Хорошо, что никому из нас, пользователей или партнеров системы, не приходится решать архитектурные вопросы. Пусть о них болит голова у тех, кто за это отвечает.
Лично я не вижу никаких существенных недостатков для нас как для разработчиков и партнеров от такой архитектуры. Она работает.

Часть 3: Битрикс для бизнеса. Взгляд сисадмина, разработчика, директора

Буду благодарен за дополнения.