Те, кто все понял, дальше могут не читать, с остальными давайте разберемся подробнее.
Я сделал небольшой пример. База с тремя справочниками: "Номенклатура", "КатегорииЦен" и "Цены". Номенклатура хранит список товаров, справочник "КатегрииЦен" - просто классификатор категорий, а справочник "Цены" подчинен номенклатуре и имеет два реквизита: "Категория" и "Цена" (Число). Таким образом в нем хранится цена для конкретного товара и конкретной категории. Достаточно стандартная ситуация. (Конечно, это можно организовать и регистром сведений или еще как-нибудь, но для примера я взял справочник. Просто так.)
Скачать базу можно тут: StaticMethods.zip
А теперь самое главное. Обработка "УстановитьЦены" выводит два списка: список товаров и, при выборе конкретного товара, в правом списке будут отображены его цены по каждой категории (с возможностью редактировать).
Обычно для чтения цены пишут функцию вроде "ПолучитьЦену", на вход которой передается товар и категория (а может еще и валюта, единица измерения или много чего, в зависимости от ваших нужд) а на выходе у нее полученная цена. Иногда такую функцию пишут и для записи цены.
Если с самими функциями все понятно, то вопрос где их положить до недавнего времени оставался открытым. В 7.7 такая функция скорее всего попала бы в глобальный модуль. В результате чего глобальный модуль со временем превращался в неподъемное собрание функций. Можно было всякими ухищрениями класть функции в обработки или внешние файлы или строго соблюдать структуру и принципы комментирования глобального модуля. Все-равно это все оказывалось неудобным или мало эффективным.
В 8.1 появились общие модули (много! много! ;-) и это существенно упростило дело. Во всяком случае "помойка функций" стала расти намного медленнее и при грамотно организованной структуре общих модулей можно было быть уверенным, что другой программист найдет вашу хитрую функцию быстрее и сможет использовать ее повторно, а не писать свою. Что безусловно хорошо, так как код используется повторно. Ну, если он вообще будет что-то искать. ;-)
Однако, всегда хочется лучшего. Например, есть функции, которые относятся исключительно к какому-либо справочнику или документу, но нужны во всей конфигурации. Можно завести общий модуль по имени справочника, но не хотелось бы. Или можно было бы положить такие в модуль объекта. Но без объекта нельзя обратиться к модулю, а не всегда хочется тянуть целый объект из базы, когда достаточно ссылки (или ссылка вообще не нужна). Т.е. с одной стороны функции нужна привязка к "классу" объектов, а с другой, конкретный объект для работы функции не требуется. В ООП такая функция обязательно стала бы статическим методом класса, а в 1С 8.2 ее можно положить в "Модуль менеджера".
Обратите внимание на то, как я вызываю функцию "ПолучитьЦену" в обработке "УстановитьЦены":
Конечно, если говорить конкретно о функции "ПолучитьЦену", то вы могли бы поместить ее и в модуль менеджера справочники "Цены" или даже в "КатегорииЦен" или еще как-нибудь. Все зависит от того как вы строите архитектуру вашего приложения и какие используете соглашения при разработке. Но в любом случае возможность создать "статический метод класса" у вас есть. Что на мой взгляд - прекрасно.
Спасибо за внимание и хорошего вам кода.
Публикация на Infostart.
Скачать базу можно тут: StaticMethods.zip
А теперь самое главное. Обработка "УстановитьЦены" выводит два списка: список товаров и, при выборе конкретного товара, в правом списке будут отображены его цены по каждой категории (с возможностью редактировать).
Обычно для чтения цены пишут функцию вроде "ПолучитьЦену", на вход которой передается товар и категория (а может еще и валюта, единица измерения или много чего, в зависимости от ваших нужд) а на выходе у нее полученная цена. Иногда такую функцию пишут и для записи цены.
Если с самими функциями все понятно, то вопрос где их положить до недавнего времени оставался открытым. В 7.7 такая функция скорее всего попала бы в глобальный модуль. В результате чего глобальный модуль со временем превращался в неподъемное собрание функций. Можно было всякими ухищрениями класть функции в обработки или внешние файлы или строго соблюдать структуру и принципы комментирования глобального модуля. Все-равно это все оказывалось неудобным или мало эффективным.
В 8.1 появились общие модули (много! много! ;-) и это существенно упростило дело. Во всяком случае "помойка функций" стала расти намного медленнее и при грамотно организованной структуре общих модулей можно было быть уверенным, что другой программист найдет вашу хитрую функцию быстрее и сможет использовать ее повторно, а не писать свою. Что безусловно хорошо, так как код используется повторно. Ну, если он вообще будет что-то искать. ;-)
Однако, всегда хочется лучшего. Например, есть функции, которые относятся исключительно к какому-либо справочнику или документу, но нужны во всей конфигурации. Можно завести общий модуль по имени справочника, но не хотелось бы. Или можно было бы положить такие в модуль объекта. Но без объекта нельзя обратиться к модулю, а не всегда хочется тянуть целый объект из базы, когда достаточно ссылки (или ссылка вообще не нужна). Т.е. с одной стороны функции нужна привязка к "классу" объектов, а с другой, конкретный объект для работы функции не требуется. В ООП такая функция обязательно стала бы статическим методом класса, а в 1С 8.2 ее можно положить в "Модуль менеджера".
Обратите внимание на то, как я вызываю функцию "ПолучитьЦену" в обработке "УстановитьЦены":
Через менеджер справочника. Мне не нужен лишний общий модуль или какие-то другие ухищрения.НоваяСтрока.Цена = Справочники.Номенклатура.ПолучитьЦену(ТекущийТовар, Выборка.Ссылка);
Конечно, если говорить конкретно о функции "ПолучитьЦену", то вы могли бы поместить ее и в модуль менеджера справочники "Цены" или даже в "КатегорииЦен" или еще как-нибудь. Все зависит от того как вы строите архитектуру вашего приложения и какие используете соглашения при разработке. Но в любом случае возможность создать "статический метод класса" у вас есть. Что на мой взгляд - прекрасно.
Спасибо за внимание и хорошего вам кода.
Публикация на Infostart.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.