Урок №1. Архитектурный кризис компонентов. Почему процедурный подход убивает ваш проект?

1. Теоретический фундамент: Почему процедурный код — это тупик?

Нарушение принципа единственной ответственности (SRP)

В процедурном компоненте файл component.php является классическим антипаттерном «Божественный объект» (God Object). Он берет на себя слишком много:

1. Валидация (Input Filtering): Приведение $arParams к типам, установка дефолтных значений.
2. Инфраструктура: Проверка подключения модулей, прав доступа.
3. Data Fetching: Прямые запросы к БД, инфоблокам или внешним API.
4. Бизнес-логика: Расчеты скидок, фильтрация по сложным условиям.
5. Кэширование: Ручное управление ключами и жизненным циклом кэша.
6. Презентация: Формирование огромного массива $arResult для шаблона.

Согласно принципу Separation of Concerns (SoC), эти ответственности должны быть изолированы. В процедурном коде они перемешаны (intertwined), что делает невозможным изменение одной части без риска сломать остальные пять.

Проблема «Глобального состояния» и неявных зависимостей

Процедурный код Bitrix полагается на глобальную область видимости и суперглобальные массивы.

• Изменение $arResult в result_modifier.php происходит неявно. Вы читаете шаблон и не понимаете, откуда взялось поле PRICE_FORMATTED, если в component.php его нет.
• IDE «слепа»: она не может отследить цепочку трансформаций данных через include файлов.
• Побочные эффекты: вы не можете гарантировать, что данные в template.php достоверны, так как любой файл в цепочке (component.php -> result_modifier.php -> component_epilog.php) может их переопределить.

2. Практическая анатомия катастрофы: Разбор антипаттернов

Эти проблемы встречаются в 90% проектов, причем как в component.php, так и в плохо написанных class.php.

Кейс А Скрытая деградация производительности (N+1 в шаблоне)

Представьте стандартный список новостей. Бизнес просит добавить имя автора для каждого элемента.

Как это делают «быстро» в result_modifier.php (legacy стиль):

        // examples/lesson-00-legacy/templates/.default/result_modifier.php

foreach ($arResult["ITEMS"] as &$arItem) {
    // АНТИПАТТЕРН: Запрос в цикле (N+1)
    // На 10 новостей мы получим 10 дополнительных запросов к БД
    $dbProp = CIBlockElement::GetProperty(
        $arItem["IBLOCK_ID"],
        $arItem["ID"],
        array("sort" => "asc"),
        Array("CODE" => "SOURCE")
    );
    if ($arProp = $dbProp->Fetch()) {
        $arItem["SOURCE_VALUE"] = $arProp["VALUE"];
    }
}

    

Кейс Б «Теневая логика» и отсутствие контракта

Когда логика размазана между основным файлом и вспомогательными. В случае с class.php это часто превращается в огромный метод executeComponent на 1000 строк.

Кейс В Cache Poisoning (Отравление кэша)

В процедурном коде и в плохом ООП-коде часто забывают про зависимость ключа кэша от всех входящих параметров.

        // Плохой пример в class.php
public function executeComponent()
{
    if ($this->startResultCache()) {
        // Данные зависят от группы пользователя, но мы не добавили её в ключ кэша!
        $this->arResult["DATA"] = MyService::getPrivateData();
        $this->includeComponentTemplate();
    }
}

    

Последствия: Утечка данных между пользователями. В class.php у нас есть системный способ управления этим через методы, который мы разберем позже.

3. Миф: class.php = Автоматически Чистый Код

Самая большая ловушка — перенести процедурный код в класс без рефакторинга.

• Процедурная лапша: 500 строк в одном файле.
• ООП-лапша: 500 строк в одном методе executeComponent.

Разницы нет. Если вы просто обернули старый код в class MyComponent extends CBitrixComponent, вы не решили проблему, а просто сменили расширение файла.

Чистый код начинается там, где появляется декомпозиция, инкапсуляция и четкие интерфейсы взаимодействия.

4. Экономика технического долга

Процедурные компоненты (и плохие ООП-компоненты) — это «быстрый кредит» под огромный процент.

1. Onboarding: Новый Middle-разработчик тратит 2-3 дня только на то, чтобы понять, как данные «гуляют» по системе.
2. Refactoring: Страх изменить одну строку, потому что она может сломать вывод в неожиданном месте.
3. Bus Factor: Если автор «лапши» увольняется, поддержка кода становится невыносимо дорогой.

5. Путь к спасению: Компонент как Программный Контракт

Переход на правильный class.php — это переход от «скрипта» к «сервису».

• Инкапсуляция: Все методы получения данных (getData()), форматирования (formatResult()) и валидации скрыты. Шаблон получает только финальный результат.
• Типизация: IDE понимает структуру вашего класса.
• Жизненный цикл (Lifecycle): Вы четко знаете последовательность вызовов. Это исключает ошибки с кэшированием.
• Наследование: Вы можете создать BaseProjectComponent для общих задач всего проекта.