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

Что же такое ООП? Ответ, который наверняка встретится в сети первым, будет звучать так: наследование, полиморфизм и инкапсуляция. Если копнуть глубже, то кроме этих понятий всплывут "передача сообщений", "класс", "абстрактный класс", "прототипы", "интерфейсы", "диспетчеризация", "миксины", "протокол", "мультиметоды" (и еще сотня других страшных слов!). Причем в каждом языке есть свой набор таких сущностей, который встречается только в этом языке или в языках похожих на него. И каждый будет утверждать, что ООП не ООП без этих понятий.

Дальнейший поиск покажет, что в сети очень много статей на тему "я не понял ООП" (в таких статьях всегда обвиняют автора в том, что он не осилил) или вопросов "как понять ООП?". Под этими статьями, обычно, сотни комментариев, где обязательно разворачиваются жаркие споры о сути ООП. Среди этих споров обязательно появятся люди, которые скажут, что JS не ООП язык, ООП без классов не бывает, а кто-то скажет, что единственные ООП-языки это Smalltalk и Lisp. Один из самых классных примеров — это статья на Хабре Я не знаю ООП. Под этой статьей 870 комментариев.

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

Кто виноват и что делать?

У ООП долгая и непростая история. Этот термин придумал Алан Кей в конце семидесятых, когда работал над языком Smalltalk.

Вот, что он сказал по этому поводу:

Для меня ООП — это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP.

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

Забавно, но в каком-то смысле он предвидел интернет

Затем появился язык C++, по мотивам которого была создана книга «Объектно-Ориентированный Анализ». В этой книге Гради Буч, создатель UML, описал те самые «полиморфизм, наследование и инкапсуляция». C++ стал мейнстримом и все последующие «ООП-языки» стали его копировать.

Когда Алана спросили про ООП в C++, он сказал следующее:

Когда я придумал ООП, я не имел в виду C++

С тех пор прошло много времени. Современное (не значит, что оно лучшее, это всего лишь текущее состояние дел) понимание ООП невероятно сильно отличается от того, что имел в виду Алан Кей. Это не значит, что его идеи умерли. Они живы, но иногда в других формах и на другом уровне. Хотя некоторые разработчики продолжают настаивать на том, что настоящее ООП — это ООП Алана, всё остальное — не настоящее. Мы не будем подробно останавливаться на этом. Главное запомнить – когда программисты начинают говорить про ООП, очень важно понимать, про какое ООП они говорят, иначе будут возникать споры и даже конфликты. ООП относится к "религиозным" темам.

Современное ООП — это не строгая обоснованная теория, в отличие от функционального или автоматного программирования. Это большой набор разнообразных подходов к организации кода и сущностей (классы, объекты и т.п.), которые иногда настолько сильно различаются в разных языках, что это приводит к совершенно удивительным ситуациям. Программисты на PHP приходят в ужас от того, что называется ООП в Ruby. Создатели Ruby, при этом, говорят, что Ruby — "настоящий" ООП язык, потому что в Ruby "всё есть объект". А Java-разработчики никогда не поверят, что в JavaScript ООП вообще присутствует.

В такой ситуации очень важно отсечь всё лишнее и найти те вещи, без которых программу назвать объектно-ориентированной не получится. Как говорят математики, найти базис (минимальный набор элементов, из которых можно вывести всё остальное).

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

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

Обучение

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

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

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