Два основных типа ООП: и треснул мир напополам…

Программисты любят спорить про ООП (объектно ориентированное программирование). Давайте копнем поглубже…

Сегодня мы имеем ситуацию разлома ООП-мира на 2 основные части: классы с иерархией классов и компоненты с сообщениями.

ООП на основе прототипов — постепенно вымирает. Потому его сильно трогать не будем.

С чего все началось?

Изначально эту идею придумал Алан Кей где то в 70х или 80х годах https://habr.com/ru/company/hexlet/blog/303754/

Часть программистов поняли идею близко к автору, а часть поняли так как смогли.

Появились 2 разные идеологии ООП:

• классы с иерархией классов
• компоненты с обменом сообщениями

Эту тему можно прочитать в библии архитекторов ПО: «Мифический человеко-месяц» автор Фредерик Брукс, 1980е годы. Там классно описана тема когда мир начал разбиваться на 2 части.

А затем пришел Майкрософт с кучей бабла и решал свои проблемы захвата рынка. Тут была история про C, C++ (Microsoft) & Objective-C (Apple).

Apple уловила основную идею Алана Кея и купила язык который поддерживал именно ее. Работа компонентов через обмен сообщений.

Microsoft купил C++ который работал на альтернативной идее иерархии классов. Так появился Visual C++.

О том как решалась бойня за рынок в те годы можно посмотреть тут:

Кратко резюме и тезисы:

• в те годы (90-е, 00-е) компании бились не за клиента, а за программистов, кто захватил программистов тот захватил рынок
• Майкрософт это понимали и начали битву за программистов
• Чтобы достичь эту цель было крайне важно пересадить программистов на Visual C++
• Так появились инвестиции в обучение и тонны учебников о том что такое C++
• А там писали о том что ООП это классы и иерархия классов (минус те факты которые были важны для настоящего ООП)

И треснул мир напополам…

Так образовалась трещина в мире ООП.

И треснул мир напополам, дымит разлом

И льется кровь, идет война добра со злом

И меркнет свет, в углах паук плетет узор…

Уматурман — Ночной дозор

Сейчас мир ООП состоит из 2х частей:

• одни думают головой и изучают историю ООП, понимают что это такое на самом деле
• а вторые идут по пути который куплен Майкроксофтом. Учебники, книги, и все такое что дается людям начиная со школы и ВУЗов… Все то что позволяет забить в голову программистам что ООП это история про классы и их экземпляры 🙂

Кто, где и в какой мир ушел?

Сегодня мир разделился на 2 части, где есть продукты которые базируются на одной из этих 2-х идеологий.

ООП как обмен сообщениями	ООП как иерархия классов
JS: — Vue — React	JS: — Angular
Ruby: Redmine	Ruby: GitLab
PHP: — WHMCS — WordPress — Drupal	PHP: — Joomla — Symfony — Laravel

Кто добро, а кто зло?

Из того что написано части можно подумать что одна из этих идеологий добро, а другая зло 🙂

Но это не совсем так. Обе идеологии правильные. Жопа там где программисты начинают использовать только одну из них.

Например Angular был одним из лидеров рынка на старте, но ввиду того что сильно ушел в классы и иерархию — уступил лидерство 2м другим игрокам которые сделали ставку на обмен сообщениями. Команда проиграла двум другим игрокам: React & Vue.

Если брать сообщество PHP, то тут безусловным лидером является WordPress, который держит более 30% рынка, за счет того что более 15 лет уже развивает идею ООП на основе обмена сообщениями. Однако WP не забывает про классы и их иерархию. Там много классов с наследованием. Но они не являются движущей силой платформы. Его часто критикуют за то что он не про ООП, но это далеко от истины. Он то как раз про настоящее ООП, то самое которое было придумано Аланом Кеем в 70х годах. Он умело использует как ООП на основе сообщений (80% логики), так и ООП на основе иерархии классов (20% логики). Причем даже пропорция на мой взгляд правильная 🙂

Про наследование, инкапсуляцию и полиморфизм

Основная жопа именно в этих 3х словах, которые программистов держат в клетке.

Все 3 термина правильные. Но в зависимости от контекста (обмен сообщениями или иерархия классов) — они выглядят сильно по разному. Потому программисты говорят одни слова, но видят разное кино и потому не могут понять друг друга. Это сложно. Очень сложно.

Наследование и инкапсуляция это очень разные способы написания кода в зависимости от того что вы сейчас пишете? Вы пишете классы и наследованием через иерархию классов? Или компоненты с наследованием через сообщения?

Вы понимаете разницу? Разницу смогу понять примерно 1% программистов. 99% вообще не поймут о чем тут речь 🙂

Инкапсуляция — примерно та же история.

Полиморфизм — вот тут вообще цирк уехал, а клоуны остались 🙂

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

В случае с первичным ООП это правильно, а в случае с ООП на основе иерархии классов эта часть часто подвергается сомнению и возникают такие завихрени как типизированный JS (TypeScript) или PHP (сильно развилось в 7+ версии). С точки зрения первичного ООП на основе обмена сообщениями это ложный путь развития. Но с точки зрения того что мы сегодня видим в тренде — это правильно. Как решить конфликт? Да хз )))

Что такое обмен сообщениями в ООП?

Есть 4 типа определения этого понятия:

1. В каких то фреймворках/языках это зовется как события (Symfony/EventDispatcher, JS/AddEventListener)
2. Где то это называется как хуки (React/WordPress/WHMCS/Redmine)
3. А где то называется как это было названо прородителем идеи — обмен сообщениями
4. Есть еще 4й очень спорный тип — Webhook, который получил развитие в ходе движения микросервисов.

Про 4й пункт можно поспорить. Но в каком то смысле он тоже может считаться частью этой идеологии.

Про первичный ООП в PHP и PSR 14

Основная проблема Симфони или Ларавел заключается в том что они на 90% основаны на ООП 2го типы (иерархия классов) и почти не используют ООП 1го типа (обмен сообщениями с компонентами).

Однако мир постепенно развивается, чары Майрософта развеиваются, и люди начинают понимать что почем. В JS это давно поняли и птм лидеры этого мира типа React.

А в PHP это начали понимать только вот вот и в 2019 году появился PSR 14 https://habr.com/ru/company/oleg-bunin/blog/450812/

Возможно через 3-5 лет все фреймворки из мира PHP (Симфони или Ларавел) догонят WordPress (он на этой механике уже 15 лет работает) в части этой идеологии и смогу представить что-то рабочее. Но это не точно.

Споры о том что ООП это говно

В мире и в рунете на Хабре часто появляются статьи о том что ООП это плохо. Что это жопа. Например:

• раз https://habr.com/ru/post/451982/
• два https://habr.com/ru/post/453836/
• три https://habr.com/ru/post/147890/

Засада в том что ребята которые пишут эти статьи слабо понимают что такое ООП на самом деле 🙂 Они думают что ООП это иерархия классов (спасибо Майкрософту). И впадают в праведный гнев.

Самое смешное то что в комментах им пишут такие же умники и пытаются противопоставить функциональное программирование )))

Обе стороны далеко в тумане и нифига не понимают про ООП.

Там встречаются единичные комменты тех кто понимает что такое ООП, но эти единичные комменты теряются в массе тех кто мыслит классами и функциями )

В чем жопа с EDA? (Event Drive Architecture)

Засада заключается в том что механизм уровня PSR-14 PHP можно написать на любом языке за 1-2 дня работы среднего программиста 🙂

Это не сложно.

Сложно другое. Внедрить сами события в код системы. У WordPress на это ушло 15 лет. Это дико сложно. Научить программистов думать событиями/сообщениями/хуками. Тем более научить думать так целое сообщество которое разбросано по всему миру.

Мышление программиста из мира иерархии классов и из мира обмена сообщениями отличается ровное также как мышление депутатов правых и левых сил. Те кто разбираются в правых и левых силах государственного управления лучше смогут понять разницу между движением иерархии классов и обмена сообщениями в мире программистов. Они очень похожи 🙂

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

Однако тут есть жопа. Если вы встретите крайне левых или крайне правых депутатов — ждите проблем. Важно уметь сочетать обе идеологии. А не пытаться топить за одну из них.

Смешной видосик в тему

Как быть с поздним связыванием, переиспользованием и полимормфизмом?

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

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

• Позднее связывание — надо сделать так чтобы код можно было менять не меняя основной код. Большинство программистов не знают как это сделать 🙂
• Полиморфизм — надо сделать так чтобы переменная могла быть разных типов. Может быть это строка? А может быть число? А может быть завтра это будет массив? Не не не… в C++ это нельзя и птм это нельзя? ))
• Переиспользование — ну это совсем жесть 🙂 Чтобы переиспользовать код надо прям замарочиться…

Мы любезно будем упоминать цитату Алана Кея…

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

Алан Кей

Переведя на язык прикладной системы это выглядит так:

• имеет некую систему, будь то сайт компании, Интернет-мгазина или CRM
• мы можем поставить новый объект (модуль, плагин, компонент, бандл)
• и этот объект заработает сразу, причем позволит менять любую часть системы, не меняя код который был до этого

В мире Java/C++ — это кажется не реальной фантазией.

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

В мире WordPress, который следует первичной идеи ООП все эти принципы соблюдаются. Ты можешь иметь Интернет-магазина, добавить плагин и он сразу начнет работать. Без модификации кода. Добавится любая часть логики которая вам нужна.

Более того — когда ядро обновится или какой то плагин — они могут обновиться сами по себе. За долю секунды. Не ломая всю систему.

Фантастика? Не совсем так 🙂 Это просто соблюдение настоящего ООП 🙂

Там применяется парадигма обмена сообщениями в первичном варианте. И это позволяет связывать компоненты в любом варианте и все это работает без изменения кода.

Итого

И треснул мир наполалам… Так бывает 🙂

Но мир постепенно развивается. Наиболее прогрессивная часть программистов начинает понимать что к чему. Иначе бы не появились такие продукты как Vue, React, WordPress, Redmine, WHMCS …

Где то начиная с 2000-х стратегия Майкрософт начала терять свою силу. То что они купили мозги программистов и начали впихивать свое понимание ООП — стало ослабевать с приходом OpenSource. Сейчас они это начали понимать. Стоит посмотреть на VS Code или новые Edge на базе Chromium. Это вполне достойные продукты.

Следствием этого перелома появился PSR-14 в PHP.

Нас ждет новый мир 🙂 Мир где ООП начнет принимать ту форму которая была задумана Аланом Кеем в 70-х годах.

Где иерархия классов, компонентность и обмен сообщениями — живут в гармонии.

Это будет новый мир. Очень прикольный. Это я заявляю как WordPress-программист с 5 годами стажа. Который вкусил эту гармонию уже по полной.

Я могу это сравнить с разработкой на Ларавел, Симфони, Vue & React. Птм что кое что там тоже делаю.

Я виде миры где есть фанаты ООП на основе иерархии классов и миры где есть фанаты ООП на основе обмена сообщениями. Там и там все плохо. Важно сочетать эти идеологии в гармонии.

На мой взгляд лучше всех это смог сделать WordPress. Наверное именно по этой причине он держит 30% рынка веб сайтов в мире и каждый год увеличивает свою долю рынка вот уже на протяжении 15 лет.