Использование структур для передачи параметров функций

Описана полезная технология для передачи большого числа параметров при вызове функций

Использование структур для передачи параметров функций

Описана полезная технология для передачи контекста через структуры.

Допустим, мы выполняем некоторый функциональный блок, например проведение некоторого документа.

На входе у нас есть некоторые параметры — П1, П2, … ПN.

Далее по мере продвижения выполнения кода на основе этих параметров вычисляются другие значения — З1, 32, … ЗM.

Функциональный блок сделан в виде набора функций Ф1 … ФK, которые вызываются друг из друга.

Параметры П и вычисленные значения З могут понадобиться в любых из этих функций.

Как добиться, чтоб значения П и З были доступны во всех нужных функциях, или в каждой из функций?

Можно завести глобальные переменные П1, П2, … ПN и З1, 32, … ЗM. Тогда проблема решена.

Но это плохое решение, т.к.:

  1. Глобальные переменные используются только на момент работы функции, в остальное время просто занимают память.
  2. Нарушается принцип изолированности функции, т.е. функция использует внешние данные.
  3. На сервере нельзя использовать глобальные переменные.

Второй вариант — во всех функциях передавать все необходимые значения П1, П2, … ПN и З1, 32, … ЗM.

Но это тоже плохое решение, т.к.:

  1. Нужно очень четко контролировать, какие переменные где нужны. Если что-то забыли, придется добавлять нужные переменные.
  2. Очень сильно растет стек, т.к. используется большое число параметров.
  3. Сложно добавить новый параметр, т.к. придется править все вызовы по передаче параметров.

Поэтому идеальное решение — использовать структуру для передачи контекста.

Обычно в своих решениях я даю ей наименование П.

При входе в блок я создаю структуру, в которой заполняю все исходные данные:

П = Новый Структура(«П1, П2, … ПN», П1, П2, … ПN);

А затем вызываю первую функцию функционального блока.

Если какая-то из функций вычисляет значение, которое понадобится другой, то это значение просто добавляется в переменную контекста:

П.Вставить(«ЗI», ЗI);

Таким образом, практически все функции блока имеют только один параметр — П.

Но не стоит увлекаться одной переменной контекста для всех участков кода. Вот пример, когда на участке лучше использовать отдельную переменную.

Пример с единой переменной:

Функция ОбойтиУровень(П)

  Если П.Уровень = 0 Тогда

    Возврат Неопределено;

  КонецЕсли;

  ТекУровень = П.Уровень;

  П.Уровень = П.Уровень — 1;

  ТекУровень = П.Уровень;

  ОбойтиУровень(П);

  П.Уровень = ТекУровень;

  ОбработатьУровень(П.Уровень);

КонецФункции

Пример с дополнительной переменной выглядит красивее:

Функция ОбойтиУровень(П, Уровень)

  Если Уровень = 0 Тогда

    Возврат Неопределено;

  КонецЕсли;

  ОбойтиУровень(П, Уровень — 1);

  ОбработатьУровень(П, Уровень);

КонецФункции

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

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

Если посмотреть код типовых (например, процедуры партионного учета), то видно, что структуры используются для агрегирования множества мелких значений (сама жизнь заставляет так поступать), иначе бы у процедур было по 20-30 параметров. Но объединение переменных в единый контекст пока еще не осуществляется, хотя переменные и путешествуют вместе по всему блоку проведения и расчета партий. Поэтому чтобы добавить свои промежуточные данные, приходится искать, в какую из имеющихся структур можно их включить.

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

 

24 Comments

  1. mrd_84

    🙂

    Reply
  2. Поручик

    (0) 1С: Бухгалтерский учет 7.7; 1С: Оперативный учет 7.7; 1С: Расчет 7.7; 1C: OpenConf 7.7

    В клюшках есть структуры? Или это глюк сайта, эти разделы сами добавляются?

    Reply
  3. Поручик

    Статья полезная новичкам, хотя идея использовать структуру для передачи параметров или контекста не нова. Сам использовал структуры ещё года три назад.

    Reply
  4. fixin

    (2) В клюшках есть списки, которыми можно моделировать структуры, подход от этого не меняется, не буквоедствуйте.

    (3) Ну вот пусть и читают. 😉

    Reply
  5. Angeros

    Коллега вам в журнализты надо было податься, столько воды из пальца высосать это надо уметь. Ну и как бы структуры для передачи параметров используются во всех типовых.

    Reply
  6. TrinitronOTV

    да уж, дискуссия….

    а передача параметров по ссылке?

    Reply
  7. fixin

    (5) но не регулярно. Типовые вообще отличаются в этом плане лоскутностью. Где-то используются, где-то тащат хвост из 10 параметров… 😉 К тому же у меня есть еще вложенные структуры для рекурсивных функций, это самоценный по себе материал.

    (6) Вы о чем? Речь идет о минимизации количества таскаемых из функции в функцию параметров.

    Reply
  8. dusha0020

    И все-таки создание списков значений в клюшке весьма трудоемкий процесс. И как быть с передачей по ссылке?

    Reply
  9. alex_bob

    У описанной технологии есть отрицательные стороны — за всё надо платить.

    1. Функция не знает, есть ли в переданной структуре нужные элементы структуры и какие они имеют типы. Следовательно всё нужно проверять внутри функции, что может влиять на производительность.

    2. На извлечение элементов из структуры тратится определенное время. Если функция будет внутри цикла, то это может быть ощутимо.

    Возможно именно поэтому такой подход и применяется не повсеместно, а лишь в некоторых местах.

    Reply
  10. Арчибальд

    (8)

    создание списков значений в клюшке весьма трудоемкий процесс

    СоздатьОбъект(«СписокЗначений») — 31 символ

    Новый Структура — 15 символов

    Т.е. трудоемкость в семерке вдвое превышает восьмерочную.

    Установить — 10 символов

    Вставить — 8 символов

    И здесь 25% выигрыша.

    Получить — 8 символов

    Свойство — тоже 8. тут трудоескость совпадает 🙁

    Reply
  11. zfilin

    (8) Ну, не такой уж и трудоемкий.

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

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

    Вообщем, это не «серебрянная пуля», но за простую минимизацию количества параметров однозначный плюс.

    И, кстати, я бы сказал, что лучше было бы передавать несколько структур, сообразно сущностям, которые объединяют параметры. Например, если в некую функцию передается «Город», «Улица», «Дом», «ФИО», «ДатаРождения», «ИНН», то возможно это логично разбить на две структуры: «Адрес» («Город», «Улица», «Дом») и «Контрагент» («ФИО», «ДатаРождения», «ИНН»). А вообще, читайте Мартина у него хорошо об этом написано.

    Reply
  12. zfilin

    (9) Ну. В 1С типы и в описании параметров не проверяются. =)

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

    Хотя, в целом согласен, что структуры могут усложнить отладку, так как скрывают детали описания «интерфейса функции».

    Reply
  13. dusha0020

    (10) Арчибальд, А как насчет этого:

    П = Новый Структура(«П1, П2, … ПN», П1, П2, … ПN);

    И этого:

    П = СоздатьОбъект(«СписокЗначений»);
    П.ДобавитьЗначение(П1,»П1″);
    П.ДобавитьЗначение(П2,»П2″);

    … до N ?

    Reply
  14. Ёпрст

    Если че, в клюшках Структура есть сто лет в обед, и Вектор и АссоциативныйВектор..

    Reply
  15. Арчибальд

    (13) Про «ДобавитьЗначение» в моем посте ни слова нет. А в контексте статьи, если начальные значения (параметры) вычисляются, и вовсе не о чем говорить.

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

    Reply
  16. Арчибальд

    (14) В клюшках есть все, кроме дурацких восьмерочных заморочек :))

    Reply
  17. zfilin

    (16) Эге! Это не заморочки, это передача параметров в конструктор объекта! =)

    Reply
  18. Ёпрст

    Кстати, Фиксин, ты прям восставший из ада!

    Тебя вроде как изгнали отовсюду ?, ан нет, живой чертяка..

    Reply
  19. Поручик

    (18) Подтверждение теории Кащея Бессмертного.

    (16) Список заморочек в студию или вы не понимаете матчасти, это две совершенно разных среды.

    Reply
  20. luns

    (18) так если человек себя ведет прилично в обществе. делиться наработками, то это же всегда хорошо.

    наверное прошел подростковый период.

    Reply
  21. fixin

    (20) я каким был таким и осталя. Обработками делился всегда. В обществе веду себя соответственно этому обществу. Что-то я не понял вашей мысли.

    Reply
  22. luns

    (21) насчет обработок верно.

    просто ранее высказывался порой не лицеприятно в адрес оппонентов и агрессивно реагировал на критику в свой адрес.

    общество за это время кардинально не изменилось, а стиль общения с тобой теперь совсем иной.

    вот я и сделал вывод что изменился ты, что очень хорошо.

    вот такая мысль.

    Reply
  23. fixin

    (22) возможно, возможно. Но когда ты Гений, постепенно перестаешь реагировать на Мосек, видимо поэтому я меньше огрызаюсь.

    Reply
  24. luns
    fixin пишет:

    перестаешь реагировать на Мосек

    Вот именно про такой стиль общения я и говорил.

    Возможно я поспешил с выводами о взрослении 🙂

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *