JS: Введение в ООП
2026-02-26 17:12 Diff
https://ru.hexlet.io/courses/js-introduction-to-oop/lessons/encapsulation/theory_unit

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

Сложно

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

В некоторых источниках под инкапсуляцией понимают сокрытие данных (data hiding) от прямого внешнего обращения (обычно с помощью ключевых слов private, protected). Более того, именно это определение захотят от вас услышать на собеседовании, но оно правильно лишь частично. Несмотря на то, что это распространенное определение, стоит разделять объединение данных с методами и сокрытие этих данных. Есть языки, например Python, в которых есть объединение данных, но нет сокрытия данных. Причем если в этих языках ввести сокрытие данных, то архитектура программ не изменится, а вот если разъединить данные и методы, то придется переписать практически весь код. Примерно такая же картина и с языками, в которых есть сокрытие данных. Если его убрать, то мало что поменяется, кроме того, что разработчикам придется быть чуть аккуратнее при работе с объектами.

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

Зачем нужно сокрытие данных, разбирается в уроке про инварианты.

Конец Сложно :)

О том, как работают методы внутри, мы поговорим в следующем уроке. А сейчас рассмотрим внешние особенности методов.

Автодополнение

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

В языках с развитой системой модулей автодополнение есть и при работе с обычными функциями. Но там в любом случае надо сначала написать правильное имя модуля. Пример из эликсира: User.getName(user). С другой стороны, существуют языки с Unified Function Call (например Nim), там обычные функции можно вызывать как методы и получать автодополнение.

Естественность

Другая особенность достаточно противоречивая. Для многих разработчиков код с методами выглядит "естественнее". С их точки зрения, абстракции с помощью данных можно строить только на базе методов. Если не объединять данные и функции в одном месте, то абстракция невозможна. Такое восприятие возникает из-за ограниченного опыта. Как правило, такой разработчик никогда не работал за пределами популярных ООП-языков и в его языке абстракции на функциях противоестественны и даже невозможны.

Это, конечно, не так. Достаточно пройти курс JS: Абстракции с помощью данных, чтобы убедиться в этом. Абстракции и моделирование реального мира существуют не только в ООП. Они существовали до и будут существовать после.

Попробуйте представить себе добавление в друзья в ООП-стиле. Кто кого должен добавить (первый друг второго или второй первого) и как не допустить рекурсии при взаимном добавлении?

Методы не нужно импортировать

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

А что делать в том случае, когда объекта нет, как в примере выше? Разработчики языков и библиотек поступают по-разному. В JavaScript обычные функции и методы спокойно уживаются вместе. Примерно то же самое происходит в Python. В Ruby и PHP (в современных фреймворках) обычные функции выглядят уже не так естественно, хотя их по-прежнему можно создавать. В Java вообще нет возможности создавать обычные функции. Любая функция будет методом. Поэтому в Java объекты создают практически на каждый чих. Это значительно раздувает программу и усложняет реализацию простых вещей. Но есть и другие языки. В Elixir и Clojure методов в текущем понимании просто нет и самое главное, они там просто не нужны, а код при этом лаконичный, простой и расширяемый.

Для имитации обычных функций в Java используют статические методы. Они позволяют работать без создания объектов.

Цепочки вызовов

Четвертая особенность – цепочки. Вспомните такой вызов:

Этот метод возвращает новую строку, у которой тоже есть методы, а значит их можно вызвать. Например:

А теперь немного магии. Что если не создавать промежуточные переменные, а делать вызовы сразу? Пробуем:

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

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

У таких цепочек есть специальное имя: fluent interface

Как и практически все остальное в современном понимании ООП, цепочки не являются чем-то эксклюзивным. Более того, они повторяют такую вещь, как пайплайн (pipeline). Если вы знакомы с командной строкой, то скорее всего не раз видели такой код:

Эта цепочка команд последовательно передает данные слева направо, пропуская их сквозь разные обработчики. Сама концепция пришла из математики и появилась задолго до программирования. Во многих языках пайплайн реализован как языковая конструкция (либо макрос в Lisp). Это настолько удачная концепция, что сейчас её стараются интегрировать во многие языки. Например, она есть в F#, OCaml, Elixir, Elm, Julia, Hack. Прямо сейчас пайплайн находится в стадии рассмотрения в JavaScript. Посмотрите пример: