Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

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

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

4 <h2>Кто виноват и что делать?</h2>

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

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

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

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

9 </blockquote>Забавно, но в каком-то смысле он предвидел интернет

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

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

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

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

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

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

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

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

18 <h2>Обучение</h2>

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

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

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