---- ВВЕДЕНИЕ \ ВОДА ----
Здравствуйте. Сижу в профильных чатах по фронтенду, и часто там возникает вопрос у новичков, как понять замыкание. Да, конечно, "малыши", бывает, не читают статьи, ленятся, где-то срезают углы. Но в подобных "уроках" часто используется профессиональный сленг, плюс нужна определенная база по программированию. В общем, информацию-ягодку проходится буквально выдирать из колючек-текстов.
Да, пусть тема избитая, изъезженная. Но, возможно, много кому данная статья поможет. В идеале, надо бы писать на технический ресурс, аля Habr или Medium. Но там надо вычитку делать, официальный деловой тон продумывать, оформление настраивать. А тут... Тут язык можно попроще, картинку в Paint нарисовал, и все довольны. Однако ягодку я постараюсь сорвать и поднести поближе. Нет, жевать за вас не буду, Но вы хотя бы руки не поцарапаете.
---- ИСХОДНЫЙ \ БАЗОВЫЙ ПРИМЕР ----
Итак, начнем. Не отходя от кассы, возьмем пример, который сегодня всплыл в чате.
Есть 2 функции: outer и inner. Названия довольно описательные. Даже на слух можно понять, где что лежит. После выполнения внешней outer функции её результат (внутренняя inner функция) записывается в переменную innerFrom. Затем полученный результат (внутренняя inner функция) вызывается, и финальный результат записывается в константу resFrom и выводится в консоль.
Вот и все замыкание. Что тут непонятного. Ха-ха. Типа пытался пошутить. Впрочем, ответы в чате в чем-то сильно сходились с моей шуткой. Но нет. Это только вводные данные текущей темы. А дальше...
Знаете, компьютер изобрели люди. Техника не возникла сама по себе. Значит и то, как устроено все это под капотом - чем-то сродни будет нам, нашим мыслям, нашему восприятию мира. Да, всегда, когда я объясняю что-то другим, я делаю упор на философскую составляющую. Код на экране без осознания того, что происходит, будет даваться на порядки сложнее. Так же и сейчас поступим.
---- ФИЛОСОФСКОЕ ПОНИМАНИЕ ВОПРОСА ----
Вообразите себе, что вам надо испечь пирог. Но вы не знаете как. И вам мама дает рецепт из своей кулинарной книги. Или вы его распечатали из интернета. Что дальше происходит? Вам надо разобрать текст на бумаге. Потом осмыслить то, что вы прочитали. А потом вам надо действовать. Взяли продукты из холодильника и ... "нарисовали сову \ испекли пирог".
Нам сейчас пирог не так важен. Сконцентрируемся на подготовительных вещах.
- разобрать текст на бумаге \ просканировать его взглядом \ понять: где буквы, где предложения, где абзацы \ где начинается один пункт, и где заканчивается другой ...
- осмыслить прочитанный текст \ понять, что это рецепт пирога, а не варенья или самогона \ в уме прикинуть количество шагов для выполнения рецепта ...
- заготовить продукты, чтобы было из чего печь пирог \ подготовить стол для готовки ...
И только потом запустить фукнцию начать выполнять шаги по рецепту. Самое интересное, что почему-то мало кто делает акцент на этих подготовительных шагах. Типа это все само собой разумеется. В результате новичок приходит с рецептом к кухонному столу и ... (простите меня за это слово) тупит \ зависает. Ну а как: стол завален фигней, продуктов не хватает, в рецепте надо разбирать мелкий шрифт... Эх, печаль. Какой уж тут пирог. Легче это дело отложить, когда будут более лучшие условия.
---- МОСТИК МЕЖДУ ФИЛОСОФСКОЙ И ТЕХНИЧЕСКОЙ МЫСЛЬЮ ----
Так вот, компьютер тоже делает все эти подготовительные шаги, что описаны выше. И без должного внимания к ним понять замыкание трудновато. Итак, что же делает интерпретатор JS, когда встречает ваш код.
Первое, что следует понять, ваш код для компьютера изначально - это просто поток букв. И этот поток букв кода надо разобрать \ просканировать \ определить, что среди этих букв есть слово function, круглые скобочки, фигурные скобочки и т.д.
Дальше распарсенный текст \ код компьютеру надо осмыслить. Забавно звучит. "Компьютер сидит вечером под окном и размышляет. А функции быть или не быть! А может сходить покушать, оперативку себе заполнить, добрее стану..." Осмысление компьютера выглядит как создание специального функционального объекта в оперативной памяти, куда он сложит все свои заметки по распарсенному ранее тексту. Вот здесь начинаются параметры функции. Вот здесь открывается тело функции. Вот здесь закрывается. А имя функции такое-то...
Для вас, новички, эта информация не видна. Она скрыта где-то в дебрях реализации движка JS. А снаружи у себя в коде вы оперируете только тем, что объявили фукнцию и вот - "её нет, она пропала" она есть. Хотите посмотреть, как выглядит этот функциональный объект официально с точки зрения спецификации Ecmascript? У меня даже скриншот с какого-то моего доклада валяется. Сейчас найду.
Зацените, как выглядит "осмысление" движком JS вашего кода фукнции, написанной в коде. Красота... Да, это пример другой функции, не из нашего исходного \ базового примера. Но сути дела это не меняет. Вы только всмотритесь. Интерпретатор и параметры определит, и строгий режим, и начало \ конец тела функции. Поймет даже, что функция написана в файле, а не модуле...
Подчеркиваю, это не запуск функции, это просто комп прочитал ваш код, и его осознал. Сохранил информацию о вашей функции куда-то к себе в память. Прямо как человек.
А дальше рецепт прочитан, осознан. Надо подготовить продукты... Функция, как рецепт - это последовательность действий, которую надо выполнить. В процессе выполнения функция будет оперировать данными \ информацией. То есть функция - это одно, а данные, с которыми функция работает - это совершенно другое. Данные, с которыми работает функция в процессе своего выполнения, лежат в отдельном месте оперативной памяти. Это место даже имеет специальное название - лексическое окружение (Lexical environment).
Почему так назвали - не знаю. Может удачнее было бы назвать local data. Типа местная \ локальная информация. Но я уже привык к Lexical environment (LE). Думаю, и вы запомните. Так что же там за данные валяются? Ответ - все, которые кажутся вам логичными:
- это и объявленные переменные внутри функции
- другие функции, объявленные внутри текущей
- и ваш нелюбимый this
- псевдомассив arguments
- параметры функций
То есть, представьте. Вы вызвали функцию. Пнули осмысленный ранее функциональный объект через специальный метод [[Call]]. Она пошла выполнять написанный вами алгоритм. Если в процессе выполнения ей понадобилась информация - она пошла в свой "чемоданчик LE", дернула тот кусок информации, который нужен - и продолжила свое выполнение. Все просто и логично.
---- БЛИЖЕ К JS \ СВОБОДНЫЕ ПЕРЕМЕННЫЕ ----
Подытожим выше рассказанную информацию более строго. Объявление вашей функции в коде (декларация) - процесс, который приведет к следующему результату. Интерпретатор распарсит текст кода функции, на результатах парсинга создат функциональный объект, созданный функциональный объект сохранит у себя в памяти в ожидании момента, когда его (функциональный объект) вызовут на исполнение. В процессе своего выполнения функция будет оперировать данными, которые хранятся в её личном, отдельном, лексическом окружении (LE).
Мы почти у цели. Сейчас вот-вот дойдем до замыкания. Но сначала надо задуматься вот над каким моментом. Думаю, уже многие из вас задали следующий правильный вопрос... Вот есть такое понятие как свободные переменные. Это та информация, которая есть \ написана в теле функции, но её нет в чемоданчике LE этой функции. Давайте даже скопирую рисунок сверху сюда, чтобы не листать туда-сюда обратно. Тебе и мне приятно. Загадка из детского журнала "Мурзилки".
Обратите внимание на функцию inner c 3 по 6 строки. Если эту функцию вызвать, то как будет выглядеть её "чемоданчик LE" ? Там будет валяться ... а вот не скажу... Проверяю, как вы читали выше материал (this, arguments, num2, res). А вот переменной num1 нет. Она не связана с текущей функцией inner. Переменная num1 свободна словно птица в небесах. И что делать по логике?
Варианты могут быть разные. И эти варианты даже реализованы в разных языках по-разному. Можете погуглить "Проблема фунарга". Но вам это не понравится. Там умные слова, которые мы не очень любим "переваривать". Хотя суть уже вам показана. Так как же поступает JS в том случае, когда идет обращение к переменной, которой нет в LE этой фукнции? Может, падает с ошибкой?
Нет, не падает с ошибкой. Идея проста. Если у ребенка нет своих денег, чтобы купить приставку, он идет и занимает их у мамы. Да, если нет своих данных, мы можем "порыться в чужом чемоданчике LE". Гениально, не правда ли? Как только выбрать среди чужих "чемоданчиков LE" тот, в котором будем искать недостающую информацию?
---- SCOPE CHAIN КАК РЕШЕНИЕ ПРОБЛЕМЫ СВОБОДНЫХ ПЕРЕМЕННЫХ ----
Заметили? Что заметили? Как что, а на рисунке видели? Слово новое: scope, область видимости. Знакомый термин, да. Все понимают, однако сформулировать определение для новичка иногда бывает проблемой. Давайте уточним понятия, чтобы мы друг друга хотя бы понимали. А над проблемой отцов и детей поразмышляем позже.
Scope или область видимости - набор информации, с которой работает выполняемый код в текущий момент. Да, вы правы, где-то мы уже об этом говорили. Чемоданчик "LE". Давайте пока договоримся, что будем считать это одним и тем же. За одним важным различием. Scope \ область видимости - философское понятие (информация, с которой работает функция), а техническое выражение этого scope - объект LexicalEnvironment, создаваемый во время исполнения функции под капотом движка JS
Итак, мы хотим, чтобы переменная num1 была в scope \ области видимости функции inner. Однако в чемоданчике LE функции inner этой переменной нет. Мы уже определили вариант решения этой проблемы: пойти и порыться в чужой области видимости. Или технически перейти в другой объект "чемоданчика LE", не связанный с нашей функцией inner. Переходя по чужим LE, вы фактически ходите по цепи кругом из этих LE. Да! Если не найдем что-то во втором чемоданчике LE, то почему бы не сходить в третий, четвертый...
Набор связанных между собой (специальной ссылкой) лексических окружений LE, расширяющих область видимости конкретной функции - scope chain. Ух, сложное определение. Каждое слово на вес золота, их надо прям прочувствовать. Хотя идея проста. Рыться в чужих чемоданчиках LE, пока не найдем нужную нам информацию для выполнения нужной нам функции.
---- ЗАМЫКАНИЕ ИЛИ "Как только выбрать среди чужих "чемоданчиков LE" тот, в котором будем искать недостающую информацию?" ----
Да, мы добрались до заветной главы. Замыкание – механизм, который связывает "чемоданчики LE". Сейчас мы разберем, как работает этот механизм. Но прежде еще немного мыслей по терминологии. Выше написанное определение, которое я еще чуть расширю позже, оно было сформулировано мною. Вы вольны не соглашаться или выразить свое определение. Тут идет игра терминов на пересечении лингвистики и разделов науки, так скажем.
Часто вы можете видеть более упрощенное \ усложненное \ другое определение. Например, возьмем определение с MDN. Замыкание - это комбинация функции и лексического окружения, в котором эта функция была определена. Однако это определение легко спутать, а впоследствии подменить тем же определением scope chain.
Для математиков замыкание вообще ассоциируется с множеством относительно заданного набора алгебраических операций, с соблюдением ряда условий. Если множество заменить на область видимости , а набор алгебраических операций на последовательность шагов алгоритма нашей функции, то тоже вроде как что-то близкое к теме. Но...
---- МЕХАНИЗМ ЗАМЫКАНИЯ В JS ----
Скопирую, пожалуй, я рисунок снова.
Вот мы все рассматривали функции inner и её проблемы. Теперь обратим внимание на функцию outer на первой строчке. Когда она будет выполняться, что будет лежать в её LE? Да, знаю, вы уже научены. Меня интересует следующее. В "чемоданчике LE" функции outer будет лежать функциональный объект функции inner. Да, функция inner была объявлена в области видимости функции outer, а значит, эта информация будет содержаться в лексическом окружении outer.
Ну раз inner лежит внутри "чемоданчика LE" outer, догадайтесь с трех раз, куда замкнет "чемоданчик LE" функции inner при её вызове? Где будем искать недостающую информацию о переменной num1 при вызове функции inner? Правильно, замыкание свяжет лексическое окружение функции inner c лексическим окружением функции outer. Благодаря чему переменная num1 при выполнении функции inner будет найдена в лексическом окружении функции outer.
Попробую сформулировать по-человечески. Если у ребенка не хватает денег на приставку, будем искать деньги в кошельке у того, где этот ребенок родился. То есть у мамы. Если у мамы денег нет, то будем искать деньги в кошельке... у папы. А вот и нет. Я вас подловил. Ищем недостающее у того, где родились. То есть, если у мамы нет денег ребенку на приставку, пойдем поищем денег у бабушки. Она добрая, любит внука =)
И еще раз, по третьему кругу. Механизм замыкания срабатывает при рождении \ декларации функции. Так как новосозданная функция родилась в родительском лексическом окружении внешней функции, то при будущем вызове новосозданной функции её уже собственное, лексическое окружение будет гарантированно привязано \ замкнуто к родительскому LE внешней функции.
---- МЕХАНИЗМ ЗАМЫКАНИЯ В JS ДЛЯ УПОРНЫХ ----
Взглянем еще раз на рисунок...
Посмотрите на созданный функциональный объект Sum. (Осознание текста вашего кода в память компьютера. Помните?) Обратите внимание на одно свойство [[Environment]]. Это свойство заполняется при создании \ декларации функции Sum текущим LexicalEnvironment выполняемого кода. На рисунке это будет LexicalEnvironment всего скрипта ./index.js. (Глобальное лексическое окружение. Там еще глобальный объект window лежит.) То есть, лексическое окружение функции Sum будет замкнуто на глобальное окружение скрипта, потому что эта функция Sum объявлена \ задекларирована в теле глобального скрипта ./index.js.
А вот теперь функцию Sum вызвали. И она для своего выполнения (execution context) готовит свой Sum LE. Правый нижний угол рисунка.
То есть, во время вызова функции Sum будет создано её личное лексическое окружение Sum LE.
И ссылка для замыкания Scope будет взята из ранее записанного в функцию Sum свойства [[Environment]].Не путайте ссылку c именем Scope с термином scope как область видимости.
Значением свойства [[Environment]] функционального объекта Sum будет являться ссылка на внешнее глобальное лексическое окружение Global LE скрипта index.js.
Потому что при выполнении кода глобального скрипта index.js было встречено и обработано текстовое объявление \ декларация функции Sum.
Таким образом, после того, как ссылка Scope лексического окружения Sum была скопирована с ссылки [[Environment]] функционального объекта Sum, область видимости функции Sum была расширена глобальной областью видимостью скрипта, образовав scope chain.
Замыкание – механизм, который при вызове функции устанавливает связь её собственного лексического окружения с внешним лексическим окружением, где эта функция была создана.
Да, вы сделали это. Хотя бы прочитали. Надеюсь, даже поняли.
---- ПОДВЕДЕНИЕ ИТОГОВ. НАКАЗАНИЕ ВИНОВНЫХ. НАГРАЖДЕНИЕ НЕПРИЧАСТНЫХ ----
Вернемся к исходному рисунку. Не помню, какой раз его уже копирую...
Вопросы для самопроверки:
1. назовите данные лексического окружения функции inner
2. назовите данные лексического окружения функции outer
3. назовите данные глобального лексического окружения
4. скажите, куда замкнуто лексическое окружение функции inner
5. скажите, куда замкнуто лексическое окружение функции outer
6. скажите, куда замкнуто лексическое окружение функции inner (тут подскажу. Оно равно null)
7. почему функция inner не упадет, если в её лексическом окружении нет переменной num1
8. в какой момент исполнения кода создается необходимая информация для замыкания
9. есть ли в коде еще свободные переменные, кроме переменной num1
10. дайте следующие определения:
---- лексическое окружение \ lexical environment
---- область видимости \ scope
---- цепочка областей видимостей \ scope chain
---- свободная переменная
---- замыкание
Да... смотрю я на это все....и понимаю, что, наверное, я вас обманул, пообещав рассказать по-человечески. Но не сердитесь. Улыбайтесь, господа. Улыбайтесь!
