В чем минусы событийно ориентированного подхода?

Насколько я понимаю, Алан Кей (тот кто придумал термин Объекто-ориентированный) старался придерживаться именно этого подхода. т.е. кто-то отправляет сообщение, а объекты в системе на него реагируют, каждый по-своему.
По сути у нас есть message bus, в который добавляется сообщение, а объекты системы слушают этот самый message bus.
В чем минусы такого подхода? Прочитал на хабре, что это один большой антипаттерн, но почему-то не уверен.
  • Вопрос задан
  • 808 просмотров
Решения вопроса 1
mayton2019
@mayton2019
Bigdata Engineer
Не претендую на правду. Просто несколько мыслей.

В чем минусы событийно ориентированного подхода?
Насколько я понимаю, Алан Кей (тот кто придумал термин Объекто-ориентированный) старался придерживаться именно этого подхода. т.е. кто-то отправляет сообщение, а объекты в системе на него реагируют, каждый по-своему.
По сути у нас есть message bus, в который добавляется сообщение, а объекты системы слушают этот самый message bus.

Мысль первая. Наследие.

Когда мы говорим о наследии Алана Кея - надо просто глянуть что он создал практически.
А создал он язык Smalltalk. Поэтому логично изучать минусы событийного подхода на
примере софта который написан с использованием Smalltalk. Кто из коллег в топике
знает примеры такого софта? Я - к сожалению не знаю.

По ссылкам википедии https://en.wikipedia.org/wiki/Smalltalk можно видеть в категории
influenced мы просто видим что Smalltalk
влиял на Java, Go, Swift. Но я здесь не согласен потому что мы не можем измерить глубину
этого влияния. Это все равно что сказать что Сталин влиял на Черчилля. Как влиял? На 10%?
Или более чем половину? Сложно. Насчет Java я тут сказал-бы что сомнительно. ООП? Может быть.
Акторы? Нет. В Java изначально нет акторов. Они существуют позже в виде фреймворков но
языком не поддерживаются.

По поводу MessageBus. Если брать технологию акторов которая используется в Erlang.
то там скорее не message bus а очереди сообщений между потоками-акторами.
Если про Smalltalk сказать нечего то про Erlang я могу сказать что на нем написаны
две единицы софта такие как RabbitMq (очень надежная и неубиваемая система MQ).
Может не супер-производительная. И CouchDb которая выделяется своей
устойчивостью ко всяким сетевым сбоям. Реклама говорит что Кауч работает
практически при мигающей сети, при обрывах и т.п. лучше чем аналогичый TCP-IP совт.

Мысль вторая. Что Кей говорил про ООП.

У меня есть цитатник. Я туда собираю некоторые слова на лытни. И иногда слова Кнута, Дейкстры
и прочих it-академиков. Вот из цитатника Кея:

I made up the term "object-oriented," and I can tell you
I did not have C++ in mind.

Что в этой прямой речи можно понять. Что господин Кей открещивается от современного ООП.
А фактически все современное ООП зеркалит то что есть в С++. Здесь вы можете со мной спорить
о первенстве (я не буду спорить я не знаю). Но абсолютно очевиден факт что мир пошел по пути
жесткой синхронщины в 80х. И пока все еще идет. Будут ли примитивные типы int/double обьектами
не суть важно. Тут важно что Кей постулирует среду в которой двигаются сообщения. Как сеть в миниатюре.
А классическое ООП С++ - лишает нас этой среды и заменяет ее вызовом метода. Никакого сообщения
в С++ нет и быть не может потому что сообщение НЕ существует в отрыве от основного потока который
инициировал вычисления. Умрет поток - развалится весь стек и параметры и все. В противоположность
в языке Erlang поток (процесс) приёмник может дохнуть много раз но стек сохраняет свою живучесть
просто повторяя вычисления заново. И здесь мне кажется и идет развилка путей.

И здесь как-раз мы может говорить о недостатках. Очевидно что у нас появляется лаг приемки-передачи
сообщения. У нас появляются мягкие гарантии времени обработки. И многое другое.

Интересно почему в 80х Алан Кей проигрывал. Я думаю что победил прагматизм. В те далекие 80-е
комьютеры были еще слабыми. Частота мерялась сотнями килогерц и мегагерцами. И в расчетах
каждый такт был важен. И красивые и академические языки такие как Lisp, Prolog, Smalltalk
просто проигрывали языку С в силу оверинжинеринга. А поскольку С++ был вначале действительно
ООП-надстройкой над С - то он предлагал и ООП-подход и скорость портабельного ассемблера.
И хотя я лично не люблю С++ (я считаю его перегруженным техническими долгами прошлого)
я признаю что бизнес выбирая С++ выбирал просто скорость вычислений. Академизм и красивые
доказательства правоты программ были тогда не нужны. Нужно чтоб банковское приложение
быстро считало кредиты и выдавало зарплаты и пенсии.

Сегодня, когда мы нежемся в сладкой неге мощных процессоров и даже (!) облаков - мы можем
себе позволить любого уровня парадигмы и абстракции. Цена 1 абстракции стала настолько дешево
стоить что нам дешевле в банках запускать Java/Net приложения и на ходу фиксить ошибки
чем долго разрабатывать на С++ и иметь неопредленнное поведение и тяжелый анализ
в случае падения. Даже такой уродец как Python взлетел как язык интеграции а не разработки.

Мысль третья. Нестандартные и асинхронные архитектуры реализованные в железе.

Недавно смотрел анонс нового процессора от Чака Мура (это тот самый Мур который создал закон имени себя).
Мне кажется это пример той самой асинхронной клетки о которой мечтал Алан Кей.

Мысль четвертая. На кого похож Алан Кей?

Не знаю как вам. :) А мне он уж очень напоминает Боливара Траска из Люди Икс Дни Минувшего будущего.

Мысль 5. Что делает Алан Кей на фото?

Бренчит на музыкальных инструментах. Наверное блюз. Блюз потерянных архитектур :)
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
trapwalker
@trapwalker
Программист, энтузиаст
Ну да, Вы перепутали сообщение и событие. Вызов метода объекта в ООП можно интерпретировать как сообщение этому объекту из конкретного места и контекста в выполняющемся коде.
Это не то же самое, что события. Нет никакой шины или очереди событий.
Для событийного программирования существуют Pub\Sub механизмы, в рамках которых есть паблишеры, которые формируют событие в любом месте и контексте кодовой базы, а есть подписчики, которые реагируют на конкретные типы событий, обрабатывают и передают их дальше или терминируют.
Этот подход иногда полезен, но часто он рубит распыляет логику по куче обработчиков. Такие системы очень сложно отлаживать, трудно тестировать, практически невозможно доказывать корректность программы для любой допустимой входной последовательности событий. Антипаттерн это потому, что после некоторого порога сложности начинает накапливаться много формальных событий и неочевидных состояний системы. Эта мешанина трудно воспринимается и анализируется человеком
Ответ написан
Griboks
@Griboks
Основной минус заключается в том, чтобы поменять мышление с активного на реактивное. Например, js работает асинхронно, что весьма непривычно для некоторых.

Дополнительный недостаток - это неэффективное использование ресурсов.

По сути у нас есть message bus, в который добавляется сообщение, а объекты системы слушают этот самый message bus.

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

Прочитал на хабре, что это один большой антипаттерн, но почему-то не уверен.

Каких только глупостей не пишут в интернетах. Советую не верить незнакомым людям.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы