Можно ли в 1С расширять методы другого расширения с помощью директивы &Вместо?

← На главную

При проектировании модульной архитектуры на базе расширений конфигурации 1С часто возникает задача: создать базовое расширение с общими интерфейсами или заготовками функций, а затем в отдельных конфигурационно-зависимых расширениях переопределять эти функции под конкретные конфигурации (например, под 1С:ERP, Управление торговлей или Бухгалтерию предприятия). Однако попытка применить директивы &Вместо, &Перед или &После к методам, объявленным в другом расширении, приводит к тому, что код второго расширения просто игнорируется платформой.

Разберем детально, почему возникает такое поведение, как устроена работа расширений в платформе 1С и какие архитектурные подходы позволяют корректно решить задачу разделения логики.

Причины поведения платформы: почему нельзя расширять расширения

Проанализируем базовые принципы работы механизма расширений в платформе 1С:Предприятие 8.3:

Отсутствие иерархии и наследования расширений. Платформа 1С строго ориентирована на модель, в которой расширение взаимодействует исключительно с объектами и кодом основной конфигурации. Расширения не могут выстраиваться в иерархические цепочки наследования относительно друг друга.
Механизм связывания директив перехвата. Директивы &Вместо, &Перед, &После (а также &ИзменениеИКонтроль) ищут метод-цель только в контексте основной конфигурации. Если общий модуль или процедура объявлены внутри первого расширения и отсутствуют в основной конфигурации, второе расширение при компиляции не находит точку перехвата и переопределение не срабатывает.
Порядок выполнения расширений. Порядок подключения расширений определяет последовательность их применения к методам типовой конфигурации. Если несколько расширений перехватывают один и тот же метод основной конфигурации через &Вместо, они выстраиваются в стек вызовов, где управление передается дальше только при явном вызове метода ПродолжитьВызов(). Но перехватить собственный метод другого расширения невозможно.

Способ 1. Шаблон проектирования «Реестр обработчиков» (Провайдеры логики)

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

Разберем реализацию по шагам:

В базовом расширении создаем общий модуль ИнтеграцияБазовыйСервер с экспортной таблицей или соответствием для хранения провайдеров, а также метод для их регистрации:


// Базовое расширение: модуль ИнтеграцияБазовыйСервер
Перем СоответствиеОбработчиков Экспорт;

Процедура ЗарегистрироватьОбработчик(ИмяИнтерфейса, ИмяМодуляОбработчика) Экспорт
    Если СоответствиеОбработчиков = Неопределено Тогда
        СоответствиеОбработчиков = Новый Соответствие;
    КонецЕсли;
    СоответствиеОбработчиков.Вставить(ИмяИнтерфейса, ИмяМодуляОбработчика);
КонецПроцедуры

Функция ПолучитьМодульОбработчика(ИмяИнтерфейса) Экспорт
    Если СоответствиеОбработчиков <> Неопределено И СоответствиеОбработчиков[ИмяИнтерфейса] <> Неопределено Тогда
        Возврат ОбщегоНазначения.ОбщийМодуль(СоответствиеОбработчиков[ИмяИнтерфейса]);
    КонецЕсли;
    Возврат Неопределено;
КонецФункции

В зависимом расширении создаем свой модуль (например, ИнтеграцияУТСервер) и при инициализации системы (в перехвате модуля сеанса или события старта) регистрируем его:


// Зависимое расширение для УТ
ИнтеграцияБазовыйСервер.ЗарегистрироватьОбработчик("СкладскойУчет", "ИнтеграцияУТСервер");

В дальнейшем базовый код просто получает нужный модуль через ПолучитьМодульОбработчика() и вызывает его экспортные методы без необходимости динамической модификации кода.

Способ 2. Динамический поиск модуля по метаданным

Если требуется вызывать специфичный код без сложной регистрации, применим динамическую проверку доступности модулей через коллекцию метаданных. Базовый функционал проверяет, подключено ли соответствующее расширение с нужным общим модулем.

Посмотрим на пример реализации вызова:


Функция ПолучитьДанныеСклада(СсылкаНаОбъект) Экспорт
    ИмяМодуляРеализации = "ИнтеграцияСпецификаСервер";
    
    // Проверяем наличие модуля среди метаданных конфигурации и расширений
    Если Метаданные.ОбщиеМодули.Найти(ИмяМодуляРеализации) <> Неопределено Тогда
        МодульРеализации = ОбщегоНазначенияКлиентСервер.ОбщийМодуль(ИмяМодуляРеализации);
        Возврат МодульРеализации.ПолучитьДанныеСклада(СсылкаНаОбъект);
    КонецЕсли;
    
    // Дефолтная логика, если расширение реализации не подключено
    Возврат Новый Структура("КодСклада, Наименование", "", "");
КонецФункции

Такой подход обеспечивает независимость: если специализированное расширение не установлено, базовый код продолжает работать стабильно, не вызывая исключений компиляции.

Способ 3. Вынесение точек расширения в основную конфигурацию

Если регламент разработки позволяет вносить минимальные изменения в основную конфигурацию (или база снята с полной поддержки), вынесем интерфейсный модуль непосредственно в основную конфигурацию:

В основной конфигурации создаем модуль ИнтерфейсПереопределяемый с пустыми заготовками функций.
В каждом расширении перехватываем методы модуля ИнтерфейсПереопределяемый через директиву &Вместо.
В перехваченном методе обязательно управляем передачей управления с помощью ПродолжитьВызов():


&Вместо("ПолучитьНастройкиИнтеграции")
Функция Расш1_ПолучитьНастройкиИнтеграции()
    Результат = ПродолжитьВызов();
    
    // Дополняем или изменяем результат для текущей конфигурации
    Результат.Вставить("ИспользоватьХарактеристики", Истина);
    Возврат Результат;
КонецФункции

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

Если требуется полностью избежать поддержки промежуточных слоев и конструкций вида Если ТипКонфигурации = "УТ" Тогда, оптимальным решением является сборка отдельных самостоятельных расширений под каждую целевую систему (МодульИнтеграции_УТ.cfe, МодульИнтеграции_ERP.cfe, МодульИнтеграции_БП.cfe).

Каждое такое расширение содержит как общую часть логики, так и специфичные вызовы к объектам конкретной конфигурации, что упрощает отладку, обновление и не порождает конфликтов между версиями.