В процессе разработки на платформе 1С часто возникает архитектурная задача: вызвать экспортный метод из модуля менеджера, находясь в контексте модуля объекта того же самого справочника, документа или другого объекта метаданных. Казалось бы, это просто, но разработчики часто стремятся сделать код универсальным, чтобы не прописывать жестко имя объекта (например, Справочники.Номенклатура), особенно если код планируется копировать между объектами или использовать в расширениях.
Давайте вместе разберем, почему в 1С нет прямой связи ЭтотОбъект.Менеджер, и проанализируем все доступные способы решения этой задачи — от стандартных средств платформы до использования функций БСП (Библиотеки стандартных подсистем).
Если проводить аналогии с объектно-ориентированным программированием (ООП), то модуль менеджера — это хранилище статических методов класса, которые относятся ко всему типу объектов в целом. Модуль объекта же описывает поведение конкретного экземпляра (конкретной записи в базе данных) и содержит динамические методы. В классическом ООП экземпляр всегда имеет доступ к статике своего класса. Подобное разделение логики часто встречается, когда применяется реализация паттерна Стратегия или другие подходы к структурированию кода. Однако в 1С эти контексты разделены: модуль менеджера — это синглтон, который всегда доступен в памяти, а модуль объекта компилируется только в момент создания экземпляра. Рассмотрим, как наладить между ними связь.
Это самый быстрый и надежный способ обращения к менеджеру без использования тяжелых конструкций. Мы можем определить тип коллекции (Справочники, Документы и т.д.) и получить доступ к конкретному менеджеру по имени объекта, которое возьмем из метаданных самого объекта. Рассмотрим этот пример кода:
// В модуле объекта
ИмяОбъекта = ЭтотОбъект.Метаданные().Имя;
Менеджер = Справочники[ИмяОбъекта];
Менеджер.КакойТоМетод(Аргумент);
Важное уточнение: данный метод требует знания того, к какой именно коллекции относится объект (справочники или документы). Если мы хотим полной универсальности, нам придется проанализировать полное имя метаданных, что подводит нас к следующему шагу.
Мало кто знает, что менеджер объекта можно инициализировать через оператор Новый, передав ему строковое описание типа менеджера. Это позволяет полностью уйти от привязки к конкретным коллекциям типа Справочники или Документы.
Проанализируем ситуацию: полное имя объекта метаданных выглядит как Справочник.Номенклатура. Для обращения к менеджеру нам нужно преобразовать это в СправочникМенеджер.Номенклатура. Реализуем это программно:
// Универсальное получение менеджера в модуле объекта
ПолноеИмяМетаданных = ЭтотОбъект.Метаданные().ПолноеИмя(); // Например, "Справочник.Товары"
СтрокаМенеджера = СтрЗаменить(ПолноеИмяМетаданных, ".", "Менеджер."); // Получим "СправочникМенеджер.Товары"
Попытка
Менеджер = Новый(СтрокаМенеджера);
Менеджер.КакойТоМетод(Параметр);
Исключение
Сообщить("Не удалось обратиться к менеджеру объекта!");
КонецПопытки;
Рассмотрим особенности этого подхода: он считается более "тяжелым", так как платформа тратит ресурсы на парсинг строки и инициализацию обращения. Однако это единственный способ получить менеджер, имея на руках только объект, без использования громоздких условий Если... ИначеЕсли.
Если ваша конфигурация построена на базе БСП (что является стандартом для современных решений 1С), то за вас уже написаны те самые "20 строк кода", которые корректно определяют менеджер объекта. Это наиболее рекомендуемый способ для промышленной разработки. Чтобы лучше ориентироваться в возможностях библиотеки, рекомендуем использовать справочник по методам БСП с примерами использования.
В БСП есть общий модуль ОбщегоНазначения, который содержит функции для получения менеджера как по ссылке, так и по полному имени метаданных. Посмотрим на примеры:
Менеджер = ОбщегоНазначения.МенеджерОбъектаПоСсылке(ЭтотОбъект.Ссылка);
Менеджер.КакойТоМетод();
ИмяМетаданных = ЭтотОбъект.Метаданные().ПолноеИмя();
Менеджер = ОбщегоНазначения.МенеджерОбъектаПоПолномуИмени(ИмяМетаданных);
Менеджер.КакойТоМетод();
Преимущество БСП: внутри этих функций реализованы проверки на типы объектов (Планы видов характеристик, Регистры сведений и т.д.), что избавляет вас от ошибок при работе с редкими типами метаданных.
Если вам часто приходится обращаться к менеджеру из разных мест модуля объекта и вы хотите, чтобы код выглядел эстетично, можно добавить небольшую функцию-помощник в самом модуле объекта.
// В модуле объекта
Функция Менеджер()
Возврат Справочники.МойСправочник; // Да, здесь есть имя, но оно локализовано в одной функции
КонецФункции
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
Менеджер().ВыполнитьОбщуюПроверку(ЭтотОбъект);
КонецПроцедуры
Давайте выясним причину, почему нельзя просто написать Метаданные.Менеджер. Основная проблема заключается в именовании коллекций в платформе 1С. В метаданных объект всегда указан в единственном числе (Справочник), а глобальный контекст для доступа к менеджерам использует множественное число (Справочники). Более того, правила образования множественного числа в русском языке не всегда прямолинейны (например, ПланВидовХарактеристик превращается в ПланыВидовХарактеристик).
Именно из-за этой лингвистической особенности платформы разработчикам приходится либо использовать БСП, либо прибегать к конструкции Новый("ТипМенеджера.Имя"), где правила именования более строгие и предсказуемые.
Проанализируем, какой метод выбрать в зависимости от ситуации:
Важный совет: При использовании динамических вызовов (через БСП или Новый) помните, что вы теряете типизацию в конфигураторе. Система не сможет подсказать вам список методов через Ctrl + Пробел. Чтобы минимизировать риски, регулярно проводите анализ конфигураций на наличие ошибок, связанных с вызовом экспортных функций. Используйте эти методы осознанно!