Сколько параметров может принимать функция
Параметры и аргументы функции
В программировании функции могут не только возвращать данные, но также принимать их, что реализуется с помощью так называемых параметров, которые указываются в скобках в заголовке функции. Количество параметров может быть любым.
Параметры представляют собой локальные переменные, которым присваиваются значения в момент вызова функции. Конкретные значения, которые передаются в функцию при ее вызове, будем называть аргументами. Следует иметь в виду, что встречается иная терминология. Например, формальные параметры и фактические параметры. В Python же обычно все называют аргументами.
Рассмотрим схему и поясняющий ее пример:
Когда интерпретатор переходит к функции, чтобы начать ее исполнение, он присваивает переменным-параметрам переданные в функцию значения-аргументы. В примере переменной a будет присвоено 100, b будет присвоено 12.
Существуют изменяемые типы данных. Для Питона, это, например, списки и словари. В этом случае данные передаются по ссылке. В функцию передается ссылка на них, а не сами данные. И эта ссылка связывается с локальной переменной. Изменения таких данных через локальную переменную обнаруживаются при обращении к ним через глобальную. Это есть следствие того, что несколько переменных ссылаются на одни и те же данные, на одну и ту же область памяти.
Необходимость передачи по ссылке связана в первую очередь с экономией памяти. Сложные типы данных, по сути представляющие собой структуры данных, обычно копировать не целесообразно. Однако, если надо, всегда можно сделать это принудительно.
Произвольное количество аргументов
Обратим внимание еще на один момент. Количество аргументов и параметров совпадает. Нельзя передать три аргумента, если функция принимает только два. Нельзя передать один аргумент, если функция требует два обязательных. В рассмотренном примере они обязательные.
Однако в Python у функций бывают параметры, которым уже присвоено значение по-умолчанию. В таком случае, при вызове можно не передавать соответствующие этим параметрам аргументы. Хотя можно и передать. Тогда значение по умолчанию заменится на переданное.
Согласно правилам синтаксиса Python при определении функции параметры, которым присваивается значение по-умолчанию должны следовать (находиться сзади) за параметрами, не имеющими значений по умолчанию.
А вот при вызове функции, можно явно указывать, какое значение соответствует какому параметру. В этом случае их порядок не играет роли:
В данном случае оба вызова – это вызовы с одними и теми же аргументами-значениями. Просто в первом случае сопоставление параметрам-переменным идет в порядке следования. Во-втором случае – по ключам, которыми выступают имена параметров.
В Python определения и вызовы функций имеют и другие нюансы, рассмотрение которых мы пока опустим, так как они требуют более глубоких знаний, чем у нас есть на данный момент. Скажем лишь, что функции может быть определена так, что в нее можно передать хоть ни одного аргумента, хоть множество:
Опять же, судя по скобкам, здесь возникает упомянутый в прошлом уроке кортеж.
Практическая работа
Напишите программу, в которой определены следующие четыре функции:
Функция getInput не имеет параметров, запрашивает ввод с клавиатуры и возвращает в основную программу полученную строку.
Функция strToInt имеет один параметр. В теле преобразовывает переданное значение к целочисленному типу. Возвращает полученное число.
Функция printInt имеет один параметр. Она выводит переданное значение на экран и ничего не возвращает.
Примеры решения и дополнительные уроки в android-приложении и pdf-версии курса
Функциональное мышление. Часть 4
После небольшого экскурса в базовые типы, мы можем снова вернуться к функциям. В частности, к ранее упомянутой загадке: если математическая функция может принимать только один параметр, то как в F# может существовать функция, принимающая большее число параметров? Подробнее под катом!
Ответ довольно прост: функция с несколькими параметрами переписывается как серия новых функций, каждая из которых принимает только один параметр. Эту операцию компилятор выполняет автоматически, и называется она «каррирование» (currying), в честь Хаскела Карри, математика, который существенно повлиял на разработку функционального программирования.
Чтобы увидеть, как каррирование работает на практике, воспользуемся простейшим примером кода, печатающим два числа:
На самом деле, компилятор переписывает его приблизительно в такой форме:
Рассмотрим этот процесс подробнее:
Переписывая функции таким образом, компилятор гарантирует, что каждая функция принимает только один параметр, как и требовалось. Таким образом, используя » printTwoParameters «, можно подумать, что это функция с двумя параметрами, но на самом деле используется функция только с одним параметром. В этом можно убедиться, передав ей лишь один аргумент вместо двух:
Если вычислить ее с одним аргументом, мы не получим ошибку — будет возвращена функция.
Итак, вот что на самом деле происходит, когда printTwoParameters вызывается с двумя аргументами:
Вот пример пошаговой и нормальной версий:
Опять же, «функция с двумя параметрами» на самом деле является функцией с одним параметром, которая возвращает промежуточную функцию.
Но подождите, а что с оператором » + «? Это ведь бинарная операция, которая должна принимать два параметра? Нет, она тоже каррируется, как и другие функции. Это функция с именем » + «, которая принимает один параметр и возвращает новую промежуточную функцию, в точности как addTwoParameters выше.
Сигнатуры каррированных функций
Теперь, когда мы знаем, как работают каррированные функции, интересно узнать на что будут похожи их сигнатуры.
Если вычислить явно каррированную реализацию, можно увидеть скобки в сигнатуре, но если вычислить обыкновенную, неявно каррированную реализацию, скобок не будет:
Скобки необязательны. Но их можно представить в уме, чтобы упростить восприятие сигнатур функций.
А в чём разница между функцией, которая возвращает промежуточную функцию, и обычной функцией с двумя параметрами?
Вот функция с одним параметром, возвращающая другую функцию:
А вот функция с двумя параметрами, которая возвращает простое значение:
Их сигнатуры немного отличаются, но в практическом смысле между ними нет особой разницы, за исключением того факта, что вторая функция автоматически каррирована.
Функции с более чем двумя параметрами
Как работает каррирование для функций с количеством параметров, большим двух? Точно так же: для каждого параметра, кроме последнего, функция возвращает промежуточную функцию, замыкающую предыдущий параметр.
Рассмотрим этот нелегкий пример. У меня явно объявлены типы параметров, но функция ничего не делает.
Сигнатура всей функции:
и сигнатуры промежуточных функций:
Сигнатура функции может сообщить о том, сколько параметров принимает функция: достаточно подсчитать число стрелок вне скобок. Если функция принимает или возвращает другую функцию, будут еще стрелки, но они будут в скобках и их можно будет проигнорировать. Вот некоторые примеры:
Трудности с множественными параметрами
Пока вы не поймёте логику, которая стоит за каррированием, она будет приводить к некоторым неожиданным результатам. Помните, что вы не получите ошибку, если запустите функцию с меньшим количеством аргументов, чем ожидается. Вместо этого вы получите частично примененную функцию. Если затем вы воспользуетесь частично примененной функцией в контексте, где ожидается значение, можно получить малопонятную ошибку от компилятора.
Рассмотрим безобидную с первого взгляда функцию:
Как думаете, что произойдет, если вызвать ее так, как показано ниже? Выведется ли «hello» на консоль? Попробуйте догадаться до выполнения. Подсказка: посмотрите на сигнатуру функции.
Вопреки ожиданиям вызова не будет. Исходная функция ожидает unit как аргумент, который не был передан. Поэтому была получена частично примененная функция (в данном случае без аргументов).
А что насчет этого случая? Будет ли он скомпилирован?
Если нет понимания каррирования, данное сообщение может быть очень загадочным. Дело в том, что все выражения, которые вычисляются отдельно (т.е. не используются как возвращаемое значение или привязка к чему-либо посредством «let»), должны вычисляться в unit значение. В данном случае, оно не вычисляется в unit значение, но вместо этого возвращает функцию. Это длинный способ сказать о том, что printfn не хватает аргумента.
Слишком много параметров
Можно получить столь же загадочные сообщения, если передать функции слишком много параметров. Несколько примеров передачи слишком большого числа параметров в printf :
Если разбить общий вызов на серию явных промежуточных функций, как делали ранее, можно увидеть, что именно происходит не так.
Дополнительные ресурсы
Для F# существует множество самоучителей, включая материалы для тех, кто пришел с опытом C# или Java. Следующие ссылки могут быть полезными по мере того, как вы будете глубже изучать F#:
Также описаны еще несколько способов, как начать изучение F#.
И наконец, сообщество F# очень дружелюбно к начинающим. Есть очень активный чат в Slack, поддерживаемый F# Software Foundation, с комнатами для начинающих, к которым вы можете свободно присоединиться. Мы настоятельно рекомендуем вам это сделать!
Не забудьте посетить сайт русскоязычного сообщества F#! Если у вас возникнут вопросы по изучению языка, мы будем рады обсудить их в чатах:
Об авторах перевода
Автор перевода @kleidemos
Перевод и редакторские правки сделаны усилиями русскоязычного сообщества F#-разработчиков. Мы также благодарим @schvepsss и @shwars за подготовку данной статьи к публикации.
Существуют ли рекомендации относительно того, сколько параметров должна принимать функция?
Я заметил, что несколько функций, с которыми я работаю, имеют 6 или более параметров, тогда как в большинстве библиотек я редко встречаю функцию, которая занимает больше 3.
Часто многие дополнительные параметры являются бинарными параметрами для изменения поведения функции. Я думаю, что некоторые из этих функций с расширенными параметрами, вероятно, должны быть реорганизованы. Есть ли правило, для какого числа слишком много?
10 ответов
Я никогда не видел руководства, но по моему опыту функция, которая принимает более трех или четырех параметров, указывает на одну из двух проблем:
Есть несколько хороших успехов:
В соответствии с «Чистым Кодексом: Руководство по гибкому программному мастерству» нуль идеален, один или два являются приемлемыми, три в особых случаях и четыре или более, никогда!
В этой книге есть глава, в которой рассказывается только о функциях, где обсуждаются большие параметры, поэтому я думаю, что эта книга может быть хорошим ориентиром в отношении того, сколько параметров вам нужно.
По моему личному мнению, один параметр лучше, чем никто, потому что я думаю, что более ясно, что происходит.
В качестве примера, на мой взгляд, второй выбор лучше, потому что более понятно, что обрабатывает этот метод:
О множестве параметров это может быть признаком того, что некоторые переменные могут быть сгруппированы в один объект или, в этом случае, много логических элементов могут представлять, что функция /метод делает больше, что одна вещь, и в этот случай лучше рефакторинг каждого из этих действий в другой функции.
Например, скажем, у вас есть класс менеджера, который просит класс 3-го класса выполнить задания.
Если вы правильно моделируете,
Если у вас нет правильной модели, метод будет таким:
Правильная модель всегда уменьшает параметры функции между вызовами метода, поскольку правильные функции делегируются их собственным классам (одна ответственность), и у них достаточно данных для выполнения своей работы.
Всякий раз, когда я вижу увеличение числа параметров, я проверяю свою модель, чтобы проверить, правильно ли я создал модель приложения.
Однако есть некоторые исключения: когда мне нужно создать объект переноса или объекты конфигурации, я буду использовать шаблон построителя для создания небольших построенных объектов перед созданием большого объекта конфигурации.
Если вы программируете на достаточно низком уровне (C, C ++, сборка), большое количество параметров может быть весьма вредным для производительности на некоторых архитектурах, особенно если функция называется большим количеством раз.
Для функций, которые вызываются очень часто, даже тот факт, что программа должна настраивать аргументы перед каждым вызовом, может повлиять на производительность ( r0 to r3 ) может быть перезаписана по вызываемой функции и должен быть заменен перед следующим вызовом), поэтому в этом отношении наилучшие нулевые аргументы.
Update:
KjMag поднимает интересную тему вложения. Вложение может каким-то образом смягчить это, поскольку это позволит компилятору выполнять те же оптимизации, которые вы могли бы сделать, если пишете в чистой сборке. Другими словами, компилятор может видеть, какие параметры и переменные используются вызываемой функцией, и может оптимизировать использование регистров, чтобы минимизировать чтение /запись стека.
Есть некоторые проблемы с inlining, хотя.
Нет, нет стандартного руководства
Но есть некоторые методы, которые могут сделать функцию с большим количеством параметров более терпимой.
Вы можете использовать параметр list-if-args (args *) или параметр dictionary-of-args (kwargs ** )
Или вы можете использовать синтаксис определения литерала объекта
Например, вот вызов JavaScript jQuery для запуска запроса AJAX GET:
Если вы посмотрите на класс ajax jQuery, вы можете установить lot (приблизительно 30) больше свойств; в основном потому, что связи ajax очень сложны. К счастью, синтаксис объектного литерала облегчает жизнь.
C # intellisense обеспечивает активную документацию параметров, поэтому нередко можно увидеть очень сложные схемы перегруженных методов.
Динамически типизированные языки, такие как python /javascript, не имеют такой возможности, поэтому гораздо чаще встречаются определения ключевых слов и описания литерала объекта.
Я предпочитаю определения литерала объекта ( даже в C # ) для управление сложными методами, поскольку вы можете явно видеть, какие свойства задаются при создании объекта. Вам придется немного поработать над аргументами по умолчанию, но в конечном итоге ваш код будет намного читабельнее. С определениями литералов объектов вы можете нарушить свою зависимость от документации, чтобы понять, что делает ваш код на первый взгляд.
IMHO, перегруженные методы сильно переоцениваются.
Примечание. Если я помню, что управление правами на чтение в режиме readonly должно работать для конструкторов литералов объектов в C #. Они по существу работают так же, как и задание свойств в конструкторе.
Если вы никогда не писали какой-либо нетривиальный код на языке динамически типизированного (python) и /или функционального /прототипа javaScript, я настоятельно рекомендую попробовать его. Это может быть просветительский опыт.
Вначале может быть страшно нарушить вашу зависимость от параметров для конечного результата, для всего подхода к инициализации функции /метода, но вы научитесь делать это гораздо больше с вашим кодом, не добавляя лишней сложности.
Update:
Я, вероятно, должен был предоставить примеры для демонстрации использования на статически типизированном языке, но сейчас я не думаю о статически типизированном контексте. В основном, я делал слишком много работы в динамически типизированном контексте, чтобы внезапно переключиться обратно.
Когда список параметров увеличивается до более пяти, рассмотрите определение структуры или объекта контекста.
Это в основном просто структура, которая содержит все необязательные параметры с некоторыми разумными настройками по умолчанию.
Но опять же, это правило, а не правило. У меня часто есть функции, которые принимают более двух параметров из-за необычных обстоятельств или простоты использования.
Очень похоже на то, как говорит Эван Плэйс, я большой поклонник просто передавать ассоциативные массивы (или сопоставимую структуру данных вашего языка) по возможности.
Таким образом, вместо (например) это:
WordPress делает много всего этого, и я думаю, что он работает хорошо. (Хотя мой примерный код выше мнимый и сам по себе не является примером из WordPress.)
Этот метод позволяет вам легко передавать много данных в ваши функции, но освобождает вас от необходимости запоминать порядок, в котором каждый должен быть передан.
Вы также оцените эту технику, когда приходит время на рефакторинг, вместо того, чтобы потенциально изменить порядок аргументов функции (например, когда вы понимаете, что вам нужно передать еще один аргумент), вам не нужно менять список параметров ваших функций.
Предыдущий answer упомянул надежного автора, который заявил, что чем меньше параметров ваши функции, тем лучше вы делаете. Ответ не объяснил, почему, но книги объясняют это, и вот две из самых убедительных причин, почему вам нужно принять эту философию и с которой я лично соглашаюсь:
Параметры относятся к уровню абстракции, который отличается от уровня функции. Это означает, что читателю вашего кода нужно будет подумать о характере и назначении параметров ваших функций: это мышление является «более низким уровнем», чем имя и назначение их соответствующих функций.
В идеале нуль. Один или два в порядке, три в некоторых случаях.
Четыре или более, как правило, плохой практики.
Как и отдельные принципы ответственности, которые другие отметили, вы также можете подумать об этом с точки зрения тестирования и отладки.
Если есть один параметр, зная его значения, тестирование и поиск ошибок с ними «относительно просто, поскольку есть только один фактор. По мере увеличения факторов общая сложность быстро возрастает. Для абстрактного примера:
Урок №13. Параметры и аргументы функций
Обновл. 11 Сен 2021 |
На предыдущем уроке мы говорили о том, что функция может возвращать значение обратно в caller, используя оператор return. На этом уроке мы узнаем, что такое аргументы в функции и что такое параметры в функции.
Параметры и аргументы функций
Во многих случаях нам нужно будет передавать данные в вызываемую функцию, чтобы она могла с ними как-то взаимодействовать. Например, если мы хотим написать функцию умножения двух чисел, то нам нужно каким-то образом сообщить функции, какие это будут числа. В противном случае, как она узнает, что на что перемножать? Здесь нам на помощь приходят параметры и аргументы.
Параметр функции — это переменная, которая используется в функции, и значение которой предоставляет caller (вызывающий объект). Параметры указываются при объявлении функции в круглых скобках. Если их много, то они перечисляются через запятую, например:
Аргумент функции — это значение, которое передается из caller-а в функцию и которое указывается в скобках при вызове функции в caller-е:
Обратите внимание, аргументы тоже перечисляются через запятую. Количество аргументов должно совпадать с количеством параметров, иначе компилятор выдаст сообщение об ошибке.
Как работают параметры и аргументы функций?
При вызове функции, все её параметры создаются как локальные переменные, а значение каждого из аргументов копируется в соответствующий параметр (локальную переменную). Этот процесс называется передачей по значению. Например:
Как работают параметры и возвращаемые значения функций?
Используя параметры и возвращаемые значения, мы можем создавать функции, которые будут принимать и обрабатывать данные, а затем возвращать результат обратно в caller.
Например, простая функция, которая принимает два целых числа и возвращает их сумму:
Результат выполнения программы:
Еще примеры
Рассмотрим еще несколько вызовов функций:
Результат выполнения программы:
С первыми двумя вызовами всё понятно.
Следующая пара относительно лёгкая для понимания:
Теперь рассмотрим вызов посложнее:
add(1, multiply(2, 3)) => add(1, 6) => 7
Последний вызов может показаться немного сложным из-за того, что параметром функции add() является другой вызов add():
add(1, add(2, 3)) => add(1, 5) => 6
Задание №1: Что не так со следующим фрагментом кода?
Задание №2: Какие здесь есть две проблемы?
Задание №3: Какой результат выполнения следующей программы?
Задание №4: Напишите функцию doubleNumber(), которая принимает целое число в качестве параметра, удваивает его, а затем возвращает результат обратно в caller.
Задание №5: Напишите полноценную программу, которая принимает целое число от пользователя (используйте std::cin), удваивает его с помощью функции doubleNumber() из предыдущего задания, а затем выводит результат на экран.
Ответы
Чтобы просмотреть ответ, кликните на него мышкой.
Ответ №1
Функция multiply() имеет тип возврата void, что означает, что эта функция не возвращает значения. Но, так как она все равно пытается возвратить значение с помощью оператора return, мы получим ошибку от компилятора. Функция должна иметь тип возврата int.
Ответ №2
Проблема №1: main() передает один аргумент в multiply(), но multiply() имеет два параметра.
Проблема №2: multiply() вычисляет результат и присваивает его локальной переменной, которую не возвращает обратно в main(). А поскольку тип возврата функции multiply() — int, то мы получим ошибку (в некоторых компиляторах) или неожиданные результаты (в остальных компиляторах).
Ответ №3
Существуют ли рекомендации относительно того, сколько параметров должна принимать функция?
Я заметил, что некоторые функции, с которыми я работаю, имеют 6 или более параметров, тогда как в большинстве библиотек, которые я использую, редко можно найти функцию, которая занимает больше 3.
Часто многие из этих дополнительных параметров являются бинарными опциями для изменения поведения функции. Я думаю, что некоторые из этих бесчисленных параметров, вероятно, должны быть реорганизованы. Есть ли руководящие указания для какого числа слишком много?
Я никогда не видел рекомендации, но по моему опыту функция, которая принимает более трех или четырех параметров, указывает на одну из двух проблем:
Трудно сказать, на что ты смотришь, без дополнительной информации. Скорее всего, рефакторинг, который вам нужно сделать, это разделить функцию на более мелкие функции, которые вызываются из родительского элемента в зависимости от тех флагов, которые в данный момент передаются в функцию.
Делая это, вы получаете несколько хороших результатов:
Идеальное число аргументов для функции равно нулю (niladic). Далее следует одно (монадическое), за которым следует два (диадическое). По возможности следует избегать трех аргументов (триадных). Более трех (полиадических) требует особого обоснования, и их не следует использовать в любом случае.
В этой книге есть глава, рассказывающая только о функциях, где параметры обсуждаются достаточно широко, поэтому я думаю, что эта книга может быть хорошим ориентиром для определения того, сколько параметров вам нужно.
По моему личному мнению, один параметр лучше, чем никто, потому что я думаю, что более ясно, что происходит.
Как пример, на мой взгляд, второй вариант лучше, потому что более понятно, что метод обрабатывает:
Применительно ко многим параметрам это может быть признаком того, что некоторые переменные могут быть сгруппированы в один объект, или, в этом случае, многие логические значения могут представлять, что функция / метод выполняет больше, чем одну вещь, и в этом случае, лучше рефакторинг каждого из этих поведений в разные функции.
Например, скажем, у вас есть класс менеджера, который просит класс 3-го класса выполнить задания.
Если вы моделируете правильно,
Если у вас нет правильной модели, метод будет таким
Правильная модель всегда уменьшает параметры функций между вызовами методов, поскольку правильные функции делегируются их собственным классам (единая ответственность), и у них достаточно данных для выполнения своей работы.
Всякий раз, когда я вижу, как увеличивается число параметров, я проверяю свою модель, чтобы увидеть, правильно ли я разработал модель своего приложения.
Однако есть некоторые исключения: когда мне нужно создать объект переноса или объекты конфигурации, я буду использовать шаблон построителя, чтобы сначала создавать маленькие построенные объекты, прежде чем создавать большой объект конфигурации.
Если вы программируете на достаточно низкоуровневом языке (C, C ++, ассемблер), большое количество параметров может сильно ухудшить производительность на некоторых архитектурах, особенно если функция вызывается большое количество раз.
Обновить:
KjMag поднимает интересную тему встраивания. Встраивание в некотором роде смягчит это, поскольку позволит компилятору выполнять те же оптимизации, которые вы могли бы выполнить, если бы писали в чистой сборке. Другими словами, компилятор может видеть, какие параметры и переменные используются вызываемой функцией, и может оптимизировать использование регистров, чтобы минимизировать чтение / запись в стеке.
Есть некоторые проблемы с наклоном, хотя.
Когда список параметров увеличится до пяти, рассмотрите возможность определения «контекстной» структуры или объекта.
Это в основном просто структура, которая содержит все необязательные параметры с некоторыми разумными значениями по умолчанию.
Нет, стандартного руководства нет
Но есть некоторые приемы, которые могут сделать функцию с большим количеством параметров более сносной.
Вы можете использовать параметр list-if-args (args *) или параметр dictionary-of-args (kwargs ** )
Или вы можете использовать синтаксис определения литерала объекта
Например, вот JavaScript-вызов jQuery для запуска AJAX GET-запроса:
Если вы посмотрите на класс jQuery ajax, вы можете установить гораздо больше (примерно 30) свойств; главным образом потому, что связь ajax очень сложна. К счастью, буквальный синтаксис объекта облегчает жизнь.
C # intellisense предоставляет активную документацию параметров, поэтому весьма часто можно увидеть очень сложные схемы перегруженных методов.
Динамически типизированные языки, такие как python / javascript, не имеют такой возможности, поэтому гораздо чаще можно увидеть аргументы ключевых слов и определения литералов объектов.
Я предпочитаю определения литералов объектов ( даже в C # ) для управления сложными методами, потому что вы можете явно видеть, какие свойства устанавливаются при создании экземпляра объекта. Вам придется проделать немного больше работы для обработки аргументов по умолчанию, но в долгосрочной перспективе ваш код будет намного более читабельным. Используя определения литералов объектов, вы можете избавиться от зависимости от документации, чтобы понять, что делает ваш код на первый взгляд.
ИМХО, перегруженные методы сильно переоценены.
Примечание. Если я правильно помню, управление доступом только для чтения должно работать для литеральных конструкторов объектов в C #. По сути, они работают так же, как установка свойств в конструкторе.
Если вы никогда не писали какой-либо нетривиальный код на языке динамически типизированного (python) и / или функционального / прототипа на основе javaScript, я настоятельно рекомендую попробовать его. Это может быть полезным опытом.
Вначале может быть страшно сломать вашу зависимость от параметров для конечного, всеобъемлющего подхода к инициализации функции / метода, но вы научитесь делать намного больше с вашим кодом, не добавляя ненужной сложности.
Обновить:
Я, вероятно, должен был предоставить примеры, чтобы продемонстрировать использование в статически типизированном языке, но в настоящее время я не думаю о статически типизированном контексте. По сути, я делал слишком много работы в динамически типизированном контексте, чтобы внезапно переключиться обратно.