Новости

Учтите, что, хотя книга и называется «Познакомьтесь, JavaScript», она не для новичков. У нее другая задача: дать обзор тем, в которых необходимо разобраться на начальном этапе изучения JS. Даже если вы уже написали достаточно кода JS, эту книгу не стоит пропускать, возможно, в ваших знаниях есть пробелы, которые необходимо заполнить перед углубленным изучением сложных тем.

Общая картина

В этой книге приведен обзор тем, в которых необходимо разобраться в начале изучения JS. Книга призвана заполнить пробелы, которые могли подвести читателей, не имеющих опыта JS, на первых порах знакомства с языком. Я также надеюсь, что книга намекает на более глубокие подробности, которые разожгут ваше любопытство и побудят больше узнать о языке.

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

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

В последней главе структура языка JS разделена на три столпа. Далее приводится краткий план того, чего можно ожидать от других книг серии и как бы я рекомендовал действовать дальше. Также не пропускайте приложения, особенно приложение Б — раздел «Практика, практика, практика!»

Столп 1: области видимости и замыкания

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

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

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

Так ведут себя области видимости в большинстве языков (так называемые лексические области видимости). Границы единиц областей видимости и принадлежность переменных к этим областям определяются во время разбора (компиляции) программы. Иначе говоря, это решение, принимаемое на стадии создания программы: расположение функций/областей видимости в программе определяет структуру областей видимости в этой части программы.

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

Первая особенность обычно называется поднятием (hoisting): все переменные, объявленные в любой точке области видимости, интерпретируются так, словно объявлены в ее начале. Вторая особенность заключается в том, что переменные, объявленные с ключевым словом var, имеют функциональную область видимости, даже если располагаются в блоке.

Ни поднятия, ни функциональной области видимости var недостаточно для того, чтобы подкрепить утверждение об отсутствии лексической видимости в JS. У объявлений let/const существует специфическое ошибочное поведение, называемое временной мертвой зоной (TDZ, Temporal Dead Zone), из-за которого могут появляться наблюдаемые переменные, которые не могут использоваться. Как бы странно ни выглядела TDZ, она также отменяет зону лексической видимости. Все это лишь уникальные особенности языка, которые должен узнать и понять каждый разработчик JS.

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

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

В книге 2, «Области видимости и замыкания», вы сможете больше узнать об областях видимости, замыканиях и работе модулей.

Столп 2: прототипы

Вторым столпом языка является система прототипов. Эта тема подробно рассматривалась в главе 3, раздел «Прототипы», но хочу просто сделать несколько замечаний относительно ее важности. JS — один из очень немногих языков, в которых объекты можно создавать явно и непосредственно, без предварительного определения их структуры в классе.

Многие годы разработчики реализовывали на основе прототипов паттерн проектирования «класс», так называемое прототипическое наследование (см. приложение А, раздел «Прототипические «классы»). Затем с появлением в ES6 ключевого слова class язык ускорил свое движение по направлению к программированию в стиле ОО/классов.

Но я считаю, что это стремление только скрывает красоту и мощь системы прототипов — способности двух объектов просто соединиться друг с другом и взаимодействовать динамически (во время выполнения функции/метода) посредством совместного использования контекста this.

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

Однако почти все внимание достается наследованию классов. А его остатки приходятся на долю функционального программирования (FP, functional programming) как своего рода «антиклассовому» подходу к проектированию программ. Меня это огорчает, потому что в результате никто не рассматривает делегирование как жизнеспособную альтернативу.

Рекомендую выделить больше времени на книгу 3, «Объекты и классы», — она показывает, что делегирование объектов имеет существенно больший потенциал, чем вы, возможно, представляли себе. Я вовсе не являюсь противником классов, но намеренно выдвигаю тезис: «Классы — не единственный механизм работы с объектами». Мне хотелось бы, чтобы как можно больше разработчиков JS задумалось над этим.

На мой взгляд, делегирование объектов намного лучше соответствует духу и стилистике JS, чем классы.

Столп 3: типы и преобразования

Безусловно, третий столп JS чаще всего упускают из виду при рассмотрении природы JS.

Абсолютное большинство разработчиков совершенно превратно представляют себе работу типов в языках программирования, особенно в JS. Волна интереса в широком сообществе JS способствовала переходу на решения со статической типизацией и инструменты с поддержкой типов вроде TypeScript или Flow.

Согласен, разработчики JS должны больше знать о типах и о том, как JS управляет преобразованиями типов. Я также согласен с тем, что инструменты с поддержкой типов могут пригодиться — при условии, что разработчики уже получили эти знания и воспользовались ими!

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

Пожалуй, этот столп важнее первых двух в том смысле, что ни одна программа JS не сможет сделать ничего полезного, если не будет правильно пользоваться типами значений JS, а также преобразованиями значений между разными типами.

Даже если вы любите TypeScript/Flow, то не сможете извлечь максимум пользы из них или методологий программирования без глубокого знания того, как сам язык обходится с типами значений.

Чтобы больше узнать о типах JS и преобразованиях, см. книгу «Типы и грамматические конструкции». Но пожалуйста, не пропускайте эту тему только потому, что вы постоянно слышали, будто всегда должны использовать === и забыть обо всем остальном.

Без изучения этого столпа вы не сможете в полной мере владеть JS.

С полным содержанием статьи можно ознакомиться на сайте "Хабрахабр":

https://habr.com/ru/company/piter/blog/581384/