это довольно популярная штука и там свое понятие актора которое может не соответствовать твоему и какое правильное хз

сча заценим

там у акктор есть своя шина данных и тд

"шина данных" = способ обмена сообщениями

общая для всех типо event кидать

в твоем мире все объект с классом

которому передаются сообщения через методы

а тут шина данных

вообще я чет полистал еще раз спор про квадрат и прямоугольник, и мне показалось, что возмущения не о том. LSP не запрещает наследовать в общем случае, легко сделать прямоугольник от которого можно наследовать квадрат, но у Роберта Мартина был конкретный пример прямоугольника, причем не какой-то извращенный, и от него как раз нельзя наследовать

и есть нечто над ними

общая для всех типо event кидать

как ESB?

не знаком на практике с esb ничего сказать не могу

могу погуглить сравнить)

и есть нечто над ними

там помимо шины данных у каждого актора еще и почтовые ящики есть

которые отделяют объекты от шины

просто то на чем базируются твои понятие о ооп это ооп из smalltalk

так что вполне себе эктор модел

просто то на чем базируются твои понятие о ооп это ооп из smalltalk

ООП из смолтака базируется на эктор модел

а в универах говорят ооп это если есть инкапсуляция, полиморфизм, наследование

и приводят примеры

а в универах говорят ооп это если есть инкапсуляция, полиморфизм, наследование

а еще просят за пивком сгонять на парах потому что голова болит

и тут пропасть в понимание)

я как-то пробовал разбираться как так произошло

вывод мир тлен

1. smalltalk не подарили эплу 2. C++ 3. smalltalk и sun не договорились о модели лицензирования 4. Java хоть и разрабатывалась под влиянием идей smalltalk но все же они многое брали у C++ дабы упростить переход. Взять хотя бы main процедуру

я как-то пробовал разбираться как так произошло

Чтобы учить не обязательно знать )

вывод мир тлен

скорее отсутствие интернета в 80-х и люди тупые

могу привести аналогию с прыгунами

(ну мол прыжки в высоту)

да я то пониаю)

а вот еще ситуация есть разные команды разработки

и у каждой команды свои термины

https://ru.wikipedia.org/wiki/%D0%A4%D0%BE%D1%81%D0%B1%D0%B5%D1%80%D0%B8,_%D0%94%D0%B8%D0%BA

вот например

и свои пониманния ооп

и свои пониманния ооп

свое "непонимание" скорее)

я в целом согласен особенно с картинкой что ты кинул и пониманием твоего ооп)

свое "непонимание" скорее)

у тебя все кто считают не как ты не правы) я тоже такой мне жена говорит)

но надо слушать что они и говорят чтобы понимать где они не правы

и если всякоманда непонимающая

у тебя все кто считают не как ты не правы) я тоже такой мне жена говорит)

не совсем. мне надо доказать что правы. До этого момента я буду сомневаться.

ее надо образовывать

у любой теории есть что то общее

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

и надо диалог строить от общего

и надо диалог строить от общего

а вот это правильно

https://ru.wikipedia.org/wiki/%D0%A4%D0%BE%D1%81%D0%B1%D0%B5%D1%80%D0%B8,_%D0%94%D0%B8%D0%BA

а к чему этот пример?

поэтому проще всего говорить что я императивный программист а не ооп

это как ОО vs FP. Я видел кучу статей на тему "посмотрите как мы отличаемся" и нигде не видел "посмотрите, мы в общем-то похожи".

:D

я считаю ооп и фп очень похожими

а к чему этот пример?

ну это еще один пример культа Карго по сути. Была стандартная техника. Чувак пробовал и у него не получалось. Он придумал новую. Новую технику отторгали

потому что хороший код ооп это хороший код фп

ну это еще один пример культа Карго по сути. Была стандартная техника. Чувак пробовал и у него не получалось. Он придумал новую. Новую технику отторгали

а, понял)

а в примерах что теорий ооп что фп всегда приводят что то заведомо плохое

а в примерах что теорий ооп что фп всегда приводят что то заведомо плохое

и тут есть делема.

посмотри на фэйсбук с его флаксами

они его противопостовляют MVC

ну и хипстеры на фп ускакали)))

или "микросервисы"

с ними интереснее

было SOA

они его противопостовляют MVC

хотя по сути одно и тоже

на микросервисах проще объяснять что пошло не так

микросервисы хороши если команд много и языки разные в командах )

но есть и минусы)

Не только же, еще масштабирование проще

ну вот у меня маленькая команда но есть вайтлейблы

ERROR: S client not available

и потому для упрощения деплоя мне микросервисы выгодно

Эх.. надо кафку на раст переписать

Эх.. надо кафку на раст переписать

неужто уперся в производительность? или баг нашел?

микросервисы хороши если команд много и языки разные в командах )

было soa (до soa были и другие штуки). Идея понравилась и получила распространение. С ростом популярности размазывалось понятие. Появились всякие EBS (центролизованные шины), вендоры которые начали выпускать инструменты под "популярное SOA" и т.д. шло время, кто-то взяли из SOA то что составляло его ценность и назвал по другому и начал вещать что мол "микросервисы это лучше чем soa"

graphql vs rest - та же история.

rest обобщили до "json api"

rest это вообще мыльный пузырь

и потому для упрощения деплоя мне микросервисы выгодно

У нас не хотят их использовать именно из-за усложнения деплоя ))))

rest это вообще мыльный пузырь

нет, не мыльный

https://www.youtube.com/watch?v=j32nn5pgm9g

некоторые считают что rest это json rpc

вообщем мнений много

и есть противоположные

У нас не хотят их использовать именно из-за усложнения деплоя ))))

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

некоторые считают что rest это json rpc

можно подумать, что это не так

а какие правильные ХЗ

Неудобное оно. Памяти много хочет, ибо жаба, еще на клиентах многое происходит: далее раскидывание по партишнам там на клиенте, что приводит к тому, что просто так увеличить партишны для топиков с компактом не получится. Еще сама она идет как набор скриптов и конфигов

потому что каждый может сделать блог и хуйнуть туда пост)

Палки и говно

Но концепция охуенна, конечно

некоторые считают что rest это json rpc

rest - это принципы которые лежат в основе WEB. Если у тебя нет hateoas и оно не используется твоими клиентами (а оно используется только людьми), тобиш мобилками например, то у тебя нет REST.

неужто уперся в производительность? или баг нашел?

Это я к этому

rest - это принципы которые лежат в основе WEB. Если у тебя нет hateoas и оно не используется твоими клиентами (а оно используется только людьми), тобиш мобилками например, то у тебя нет REST.

что за hateoas

что за hateoas

элементы гипермедиа. В контексте web - теги form и a (и link еще)

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

У нас косяк с деплоем, из-за этого деплой кучи штук и не хотят. Я вообще проблем не вижу, если деплой нормально организовать

это те теги которые позволили рости WEB-у бесконечно

У нас косяк с деплоем, из-за этого деплой кучи штук и не хотят. Я вообще проблем не вижу, если деплой нормально организовать

что за косяк? может можно его пофиксить без микросервисов?

@ployd так норм книжка?

rest - это принципы которые лежат в основе WEB. Если у тебя нет hateoas и оно не используется твоими клиентами (а оно используется только людьми), тобиш мобилками например, то у тебя нет REST.

а как же rest state less легкая масштабируемость, транспортный протокол http ?

@ployd так норм книжка?

Вроде как да, многие советуют. Сам не читал, вот и спрашиваю

и прочие велости из вики_

Вроде как да, многие советуют. Сам не читал, вот и спрашиваю

полистаю, пока из описания хорошо про базворды)