Каталог решений - Модуль менеджера или статические методы класса?

Собственно, суть статьи уже отражена в ее названии и те, кто все сразу понял, могут дальше не читать. Все нижеизложенное писалось для таких же, как я, новичков в программировании, для тех, кто при виде новой сущности «Модуль менеджера» подумал: «Что за черт! Мало что ли общих модулей?»

Итак, для начала немного «пожуем» ООП.

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

Конечно, технически все это наверное не относится к 1С, но статические методы это не только особый способ обращения к методам, но и часть парадигмы ООП, определяющая сам стиль программирования.

Как мы можем использовать все это на практике? Рассмотрим пример.

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

Небольшой исторический экскурс. В 1С 7.7 было только одно место где можно было описывать функции сразу доступные отовсюду — это глобальный модуль (про разные ухищрения говорить не будем). И в больших конфигурациях он, несмотря на все усилия по сохранению в нем порядка, обычно превращается в «помойку функций», в которой очень сложно что-либо найти или даже разобраться в логике работы.

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

Но вернемся к нашей функции ПолучитьСписокОбязательныхРеквизитов. Конечно, можно поместить ее в модуль формы, но тогда она не будет доступна из других частей конфигурации (без получения формы), а узнать какой реквизит обязателен для заполнения может понадобиться когда угодно, например в какой-нибудь обработке заполнения. Поэтому лучше было бы поместить ее в модуль объекта. Но нужно помнить, что в 8.2 нельзя просто так обратиться к методам модуля объекта (без записаного объекта или вызова «ДанныеФормыВЗначение»), а проверить реквизиты нужно. К тому же для вызова метода конкретный объект по сути не нужен.

И вот наступил тот самый момент, когда две части этой статьи сходятся в одной точке. Такую функцию можно назвать «статическим методом класса», так как для ее работы не нужен конкретный экземпляр класса (объект, конкретный документ), но она очень тесно логически связана с самим классом, обязательность-то мы проверяем у конкретного вида документа. И ее можно смело помещать в модуль менеджера этого документа. К тому же ее вызов очень изящно оформляется через объект «Документы»:

спОбязателньыеРеквизиты = Документы.Заказ.ПолучитьСписокОбязательныхРеквизитов(Объект.ВидЗаказа);

Надеюсь, теперь всем, кто дочитал до этого места понятно зачем же можно (и нужно) использовать модуль менеджера.

Спасибо за внимание и хорошего вам кода.

Черновик статьи в блоге автора.