Многие спорят про архитектуру WordPress. Плохая она или хорошая? Программисты любят спорить про ООП. И среди программистов популярно мнение что у WP плохая архитектура. Давайте копнем поглубже…
Введение
Многие говорят что WordPress это не про ООП. Про ООП это что то типа Laravel или Symfony.
Я вот тут интервью проходил и мне так и сказали:
Мы видим что у вас много опыта про WordPress. А вы что то знаете про ООП?
ООП-программист
Для тех кто совсем не в теме стоит прочитать русскую википедию, раздел: Различные ООП-методологии.
3 типа ООП
Если кратко, то сегодня википедия знает про 3 типа ООП:
- Класс-ориентированное программирование: то что 99% программистов думаю что это ООП. Потомок Ивана Сазерленда.
- Компонентное программирование: парадигма которая изначально имелась ввиду как ООП автором этой темы – Аланом Кеем (Alan Curtis Kay)
- Прототипное программирование – используется в JS и др. языках, но особой силы и популярности так и не получила.
Сегодня мы имеем ситуацию разлома ООП-мира на 2 основные части: экземпляры с иерархией классов и компоненты с потоком сообщений.
ООП на основе прототипов – постепенно уходит. Но все же в JS мире еще имеет какое то значение.
С чего все началось?
Изначально эту идею придумал Алан Кей где то в 60х или 70х годах 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 статьи в тему про настоящее ООП
- «Классы — это не объектно»: интервью Егора Бугаенко с Дэвидом Уэстом
- ООП будущего: Барух Садогурский и Егор Бугаенко о том, как мы будем программировать через 20 лет
И треснул мир напополам…
Так образовалась трещина в мире ООП.
Можно сказать что образовалось 2 разных мира ООП:
- мир классов – где важно знать паттерны, выстраивать иерархию классов и как правильно назвать папки с файлами
- мир сообщений – важно понимать события, хуки, сообщения, триггеры – кто где на что реагирует
Есть туча фреймворков на любом языке про эти 2 мира, но программисты которые смогли осилить 1 мир – думают что кодеры из другого мира какие то не правильные.
По сути это выглядит как война добра со злом.
И треснул мир напополам, дымит разлом
И льется кровь, идет война добра со злом
И меркнет свет, в углах паук плетет узор…
Уматурман – Ночной дозор
Сейчас мир ООП состоит из 2х частей:
- одни думают что ООП это про классы, иерархию классов, и SOLID, то как обучают в школе и вузах
- другие идут по пути WP – про композицию, события, сообщения, GRASP
Цитаты Алана Кея про ООП
Которые помогают понять лучше что это такое.
- Я изобрел понятие «объектно-ориентированный», но могу заявить, что не имел в виду C++ при этом.
- Мне жаль, что давным давно я использовал термин «объект» для этой темы, потому что из-за этого многие люди фокусируются на меньшей из идей.
- Большая идея это «сообщения»
- Я считал объекты чем-то вроде биологических клеток, и/или отдельных компьютеров в сети, которые могут общаться только через сообщения.
- Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.
- Я не против типов, но мне не знакома ни одна система типов, которая не вызывала бы боли. Так что мне все еще нравится динамическая типизация.
- Одна из ключевых идей: система должна продолжать работу во время тестирования о особенно во время произведения изменений. Даже крупные изменения должны быть поэтапными и занимать не больше доли секунды.
- Большинство программ на сегодняшний день подобны египетским пирамидам из миллиона кирпичиков друг на друге и без конструктивной целостности — они просто построены грубой силой и тысячами рабов.
- Проблема в слабых, плохо масштабируемых идеях и инструментах, лени, нехватке знаний и т.д.
- Мой опыт в математике заставил меня понять, что каждый объект может иметь несколько алгебр, они могут объединяться в семейства, и это может быть очень полезным.
- ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP.
Кто, где и в какой мир ушел?
Сегодня мир разделился на 2 части, где есть продукты которые базируются на одной из этих 2-х идеологий.
ООП как компоненты с обменом сообщений | ООП как классы с иерархией |
JS: – Vue – React | JS: – Angular |
Ruby: Redmine | Ruby: GitLab |
PHP: – WHMCS – WordPress – Drupal – FreeScout | PHP: – Joomla – Symfony – Laravel |
Кто добро, а кто зло?
Из того что написано части можно подумать что одна из этих идеологий добро, а другая зло 🙂
Но это не совсем так. Обе идеологии правильные. Беда там где программисты начинают использовать только одну из них.
Например Angular был одним из лидеров рынка на старте, но ввиду того что сильно ушел в классы и иерархию – уступил лидерство 2м другим игрокам которые сделали ставку на компоненты и обмен сообщениями. Команда проиграла двум другим игрокам: React & Vue.
Если брать сообщество PHP, то тут безусловным лидером является WordPress, который держит более 40% рынка, за счет того что более 15 лет уже развивает идею ООП на основе обмена сообщениями. Однако WP не забывает про классы и их иерархию. Там много классов с наследованием. Но они не являются движущей силой платформы. Его часто критикуют за то что он не про ООП, но это далеко от истины. Он то как раз про настоящее ООП, то самое которое было придумано Аланом Кеем в 70х годах. Он умело использует как ООП на основе сообщений (80% логики), так и ООП на основе иерархии классов (20% логики).
Про наследование, инкапсуляцию и полиморфизм
В этих 3х словах очень много путаницы, которые программистов держат в клетке.
Все 3 термина правильные. Но в зависимости от контекста (обмен сообщениями или иерархия классов) – они выглядят сильно по разному. Потому программисты говорят одни слова, но видят разное кино и потому не могут понять друг друга. Это сложно.
Наследование и инкапсуляция это очень разные способы написания кода в зависимости от того что вы сейчас пишете? Вы пишете классы и наследованием через иерархию классов? Или компоненты с наследованием через сообщения?
Инкапсуляция – примерно та же история. В классах она делается на классах, а в сообщениях оно может работать через неймспейсы.
Полиморфизм – изначально идея была такова что переменные могут иметь разные типы данных: строка, массив, число, null.
В случае с первичным ООП это правильно, а в случае с ООП на основе иерархии классов эта часть часто подвергается сомнению и возникают такие завихрени как типизированный JS (TypeScript) или типы в PHP (сильно развилось в 7+ версии).
Ввиду того что полиморфимз изначально подразумевал динамическую типизацию, за которую топил Алан Кей, то вот в мире где строгая типизация взяла верх – для полиморфизма пришлось придумать очень странные определения.
Но если глядеть в истоки – то полиморфизм не так сложно понять.
Про первичный ООП в 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 лет работает) в части этой идеологии и смогу представить что-то рабочее. Но это не точно.
Хотя можно найти промежуточные решения – например FreeScout, который базируется на Laravel & классах, в итоге для реализации модульной архитектуры взяли в качестве диспетчера сообщений Eventy. По сути смогли реализовать некий гибридный вариант.
Обмен сообщениями или EDA (Event Driven Architecture)
Засада заключается в том что механизм уровня PSR-14 PHP можно написать на любом языке за 1-2 дня работы среднего программиста.
Это не сложно.
Сложно другое. Внедрить сами события в код системы. У WordPress на это ушло 15 лет. Это очень сложно. Научить программистов думать событиями/сообщениями/хуками. Тем более научить думать так целое сообщество которое разбросано по всему миру.
Мышление программиста из мира иерархии классов и из мира обмена сообщениями отличается ровное также как мышление христиан от мусульман. По сути можно сказать что это разные религии. Но как и в религиях – наиболее опытные искатели могут заявить о том что все они про одно, просто есть детали и разные слова.
Смешной видосик в тему
AOP – аспектно ориентированное программирование
Аспе́ктно-ориенти́рованное программи́рование (АОП) — парадигма программирования, основанная на идее разделения функциональности для улучшения разбиения программы на модули.
Сила WordPress в том что ему это удалось. Вся система по сути базируется на модулях – плагинах и темах.
И главная фишка этих решений в том что можно брать и использовать готовые компоненты под разные задачи.
Никто в мире кроме WordPress не смог реализовать эту фичу на столь высоком уровне. Только WP.
А как это удалось? Это отдельная большая тема на целую книгу. Главное понять что тут это удалось.
Вопросы и ответы
Итого про WordPress & ООП
Мир постепенно развивается. Наиболее прогрессивная часть программистов начинает понимать что к чему. Иначе бы не появились такие продукты как React, WordPress, FreeScout, Redmine, WHMCS … где больший акцент смещен в EDA, AOP и ООП на классах там если и играет то вспомогательную роль.
Где то начиная с 2000-х стратегия Майкрософт начала терять свою силу. То что они купили мозги программистов и начали впихивать свое понимание ООП – стало ослабевать с приходом OpenSource. Сейчас они это начали понимать. Стоит посмотреть на VS Code или новые Edge на базе Chromium. Это вполне достойные продукты.
Следствием этого перелома появился PSR-14 в PHP.
Нас ждет новый мир 🙂 Мир где ООП начнет принимать ту форму которая была задумана Аланом Кеем в 60-70-х годах.
Где иерархия классов, компонентность и обмен сообщениями – живут в гармонии.
На мой взгляд лучше всех это смог сделать WordPress. Наверное именно по этой причине он держит 40% рынка веб сайтов в мире и каждый год увеличивает свою долю рынка вот уже на протяжении 15 лет.
Переведя на язык прикладной системы это выглядит так:
имеет некую систему, будь то сайт компании, Интернет-мгазина или CRM
мы можем поставить новый объект (модуль, плагин, компонент, бандл)
и этот объект заработает сразу, причем позволит менять любую часть системы, не меняя код который был до этого
В мире Java/C++ — это кажется не реальной фантазией.
Спорно. А как же OSGi?
> Спорно. А как же OSGi?
технически на любом языке и платформе можно написать модульность и событийность.
даже если его нет, то основу можно написать за 3-4 дня с учетом тестов.
например в Симфони и Ларавель, есть EventDispatcher. из коробки. который позволяет делать все что нужно.
другой вопрос какой процент людей из сообщества умеют его правильно готовить и применять?
а если взять пример типа FreeScout (на базе Laravel), то по какой то причине авторы отказались от типового EventDispatcher и прикрутили туда похожий, но другой компонент.
в общем не все так просто ) если даже механизм есть, это не значит что с его помощью можно построить модульность и событийность, а даже если можно, то не факт что программисты это осилят.
так и живем )