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

Совсем иная ситуация с «in-house» решениями. Тут нет кошмара под названием «обновления опять все затерли» и можно выстраивать структуру приложения исходя из своих предпочтений. Вот здесь модули менеджеров прикладных объектов могут принести огромную пользу.

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

Модули менеджеров прикладных объектов позволяют расширить возможности системных менеджеров, снабдив их дополнительным функционалом. Если ты имеешь опыт разработки на объектно-ориентированных языках программирования, то сразу можешь ассоциировать отдельную процедуру/функцию, описанную в модуле менеджера прикладного объекта, как метод объекта.

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

Детали хитрого поиска оставим за кадром, а подумаем, как можно оформить такой код. Поскольку в условии задачи четко сказано, что алгоритм будет использоваться во многих местах, мы обязаны его описать в экспортной функции. Проще всего запихнуть ее в какой-нибудь общий модуль и обращаться примерно так:

СписокОсобыхКонтрагентов = КакойТоОбщийМодуль.ПолучитьСписокОсобыхКонтрагентов();

Выглядит весьма недурно, но теперь попробуем представить себя в шкуре другого разработчика. Как он должен узнать, что функция ПолучитьСписокОсобыхКонтрагентов() описана именно в «КакойТоОбщийМодуль»? Если по названию этого модуля хоть как-то можно провести параллель со справочником «Контрагенты», то все не так плохо.

Хуже, когда модуль называется «СборникФункций» и содержит коллекцию решений на все случаи жизни. Скажу из опыта, что ни один новый разработчик не будет ковыряться в такой «каше», ища нужную функцию. А если и будет, то трижды проклянет человека, кто эту функцию туда засунул.

Вот тут менеджеры модулей прикладных объектов могут сослужить хорошую службу. Если описать нашу функцию с хитрым алгоритмом поиска в модуле менеджера прикладного объекта «Справочники.Контрагенты», то вызывать ее будем так:

СписокОсобыхКонтрагентов = Справочники.Контрагенты.ПолучитьСписокОсобыхКонтрагентов();

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

Резюме

  • Модуль менеджера прикладного объекта позволяет расширить функциональность системных менеджеров;
  • Модуль менеджера приносит в код чуточку красоты и логичности;
  • Модуль менеджера — стандартная фича, и не нужно стесняться ей пользоваться;
  • Нет ничего лучше, когда код располагается в специально предназначенном для этого месте.