ML
а есть в чятике адепты изначального ооп по кею? с передачей сообщений и акторными идеями?
Size: a a a
2020 March 27
AK
Ну я бы сказал, что я скорее за. Хотя тут тоже не надо в крайности ударяться.
ты используешь акторы какие-то? корутинс, квазра или акка?
AN
ты используешь акторы какие-то? корутинс, квазра или акка?
Нет, зачем? Если мы говорим об идее, то акторы сами по себе не нужны. Любой объект - актор
VP
ну это тогда частный случай говнокода, хероту на любой парадигме можно сделать
Это не говногод, это распространённый подход. Я не говорю, что это плохо (это же популярно, а значит легко понимать), но оно не очень объекто-ориентировано.
AK
Скорее это просто самый распространенный подход в то время, когда большенство текущих опытных разработчиков училось. Обьективно я не вижу больших преимуществ перед структурным программированием. Гошечка нифига не сложнее джавы ее, хотя там ооп не особо виднеется.
гошечка гораздо проще, это как молоток взял и пошёл. собсвенно в такой ситуацию бедность языка играет на руку даже, не сидишь не думаешь как сделать красивее или элегантнее какие абстракции решат задачу лучше, как выстроить систему типов... нет там нихуя, копипастишь и обмазываешь csp
AN
Это не говногод, это распространённый подход. Я не говорю, что это плохо (это же популярно, а значит легко понимать), но оно не очень объекто-ориентировано.
Очень даже, если инкапсуляция есть.
VP
Очень даже, если инкапсуляция есть.
Почти вся логика оперирует тупыми струтурами с публичным состоянием, инкапуляцией и не пахнет
D
гошечка гораздо проще, это как молоток взял и пошёл. собсвенно в такой ситуацию бедность языка играет на руку даже, не сидишь не думаешь как сделать красивее или элегантнее какие абстракции решат задачу лучше, как выстроить систему типов... нет там нихуя, копипастишь и обмазываешь csp
Ты говоришь, как будто в итоге обязательно получится неподдерживаемое говно. Однако огромные энтерпрайзы его счастливо используют, включая гуглы с амазонами, а там люди умеют считать, насколько их тормозит технический долг.
D
То, что люди не обмазываются ненужными и лишними абстракциями - это хорошо.
D
Ты говоришь, как будто в итоге обязательно получится неподдерживаемое говно. Однако огромные энтерпрайзы его счастливо используют, включая гуглы с амазонами, а там люди умеют считать, насколько их тормозит технический долг.
Умеют считать, но и денег у них сильно больше на то, чтобы быть не эффективными и писать велосипеды под себя.
D
Большие корпорации берут маркетингом, распостранением на рынке, деньгами и инновациями (иногда). Продукты их не лучше, а иногда даже и хуже по качеству, чем у маленьких команд.
AK
Ты говоришь, как будто в итоге обязательно получится неподдерживаемое говно. Однако огромные энтерпрайзы его счастливо используют, включая гуглы с амазонами, а там люди умеют считать, насколько их тормозит технический долг.
нее, наоборот в итоге часто получается каноничный kiss.
даже в довольно крупные проекты. если залазить, не смотря на внешную пиздецовость и ощущение помойки - внутри очень даже читабельны и можно понять, что происходит
даже в довольно крупные проекты. если залазить, не смотря на внешную пиздецовость и ощущение помойки - внутри очень даже читабельны и можно понять, что происходит
D
Напомню, это лишь к тому, что ООП - не самый простой подход. Структурный проще в большенстве юзкейсов. А иммутабельность, чистота функций и вынесение каждого класса в отдельную абстракцию нужно далеко не всегда.
AD
хм, а как в БД хранят типы? допустим, у нас есть какой-нибудь заказ в Ozon и там есть состояния ACCEPTING, PACKAGING, WAITING, DELIVERING
если мы берем типы, то каждое из этих состояний - отдельный тип с ограниченным набором полей. но в БД же не станешь класть по разным таблицам. (понимаю, что а) можно и по разным таблицам, б) заказ на Ozon может быть не лучшим примером)
если мы берем типы, то каждое из этих состояний - отдельный тип с ограниченным набором полей. но в БД же не станешь класть по разным таблицам. (понимаю, что а) можно и по разным таблицам, б) заказ на Ozon может быть не лучшим примером)
QH
Я не в курсе деталей, как именно сформулировал ООП Алан хромаКей.
Я скорей против неверного понимания ООП — сеттеров, мутабельнодрисни, императивнодрисни.
Я скорей против неверного понимания ООП — сеттеров, мутабельнодрисни, императивнодрисни.
AA
хм, а как в БД хранят типы? допустим, у нас есть какой-нибудь заказ в Ozon и там есть состояния ACCEPTING, PACKAGING, WAITING, DELIVERING
если мы берем типы, то каждое из этих состояний - отдельный тип с ограниченным набором полей. но в БД же не станешь класть по разным таблицам. (понимаю, что а) можно и по разным таблицам, б) заказ на Ozon может быть не лучшим примером)
если мы берем типы, то каждое из этих состояний - отдельный тип с ограниченным набором полей. но в БД же не станешь класть по разным таблицам. (понимаю, что а) можно и по разным таблицам, б) заказ на Ozon может быть не лучшим примером)
интами
QH
хм, а как в БД хранят типы? допустим, у нас есть какой-нибудь заказ в Ozon и там есть состояния ACCEPTING, PACKAGING, WAITING, DELIVERING
если мы берем типы, то каждое из этих состояний - отдельный тип с ограниченным набором полей. но в БД же не станешь класть по разным таблицам. (понимаю, что а) можно и по разным таблицам, б) заказ на Ozon может быть не лучшим примером)
если мы берем типы, то каждое из этих состояний - отдельный тип с ограниченным набором полей. но в БД же не станешь класть по разным таблицам. (понимаю, что а) можно и по разным таблицам, б) заказ на Ozon может быть не лучшим примером)
enumD
string key :)
AD
и куча nullable полей?
а консистентность стейта - как-нибудь вдруг получится?
а консистентность стейта - как-нибудь вдруг получится?