DI, DI-контейнеры, аспектно-ориентированное программирование в Python vs Java. Чистый код, 11 глава

[@mihailbury240]

Спасибо! Прекрасный ролик. Очень понравилось упоминание библиотеки punq, обязательно попробую в использовании

[@t0digital]

Такие видео с разбором хороших ИТ-книг выходят в нашем книжном клубе несколько раз в неделю. Присоединяйтесь и читайте вместе с нами botanim.to.digital

[@alexdubkov6998]

Наконец то простое и понятное объяснение DI на примере питона. Спасибо!

[@tur8008]

Леха, ты посланник с небес! Респект! Закончу с проектом (забрал все силы) приду к тебе в ботанский клуб, как минимум.

[@vorontsovru270895]

Я начинал свой путь в программировании как раз с питона в далёком уже 2010м году, сейчас же уже больше 7 лет пишу код на шарпе. Каково же было моё удивление, когда я наткнулся на данный ролик: DI на питоне... Вот что значит в продакшене на питоне почти 10 лет ничего не писал)

[@antondoronin1261]

Представление о технологиях Java несколько устаревшее. Не упомянуто тут магии Spring, Micronaut и Quarkus, на голеньких спеках JavaEE (которое теперь Jakarta EE) мало где пишут. "Чистый код" - далеко не новая книжка, но "это база".

[@t0digital]

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

[@ЕгорВасильев-х7ж]

Насчет АОП интересно конечно, тоже задумывался для JS делать что-то похожее при помощи Proxy для обьектов, но сложно код выглядит в итоге (для функций будет так же как и для Питона +/-, возможно в мире ФП это можно еще упростить, назвав композицией функций) С другой стороны SRP Мартина, где примерно решается как class LoggingA и class A, где первый наследуется от A, логирует и дергает предка. С учетом проверки пользователя - уже начинает разростаться цепочка наследования, может это и нормально, но тоже смущает. Даже скорее наличие консрукции вроде class PermissionsCheckingA extends LoggingA Напрашивается вывод в порядке предпочтения: Функциональщина -> SRP -> AOP 🤔 Спасибо большое за выпуск, крайне занятно

[@Артём-ы1ю6н]

Сделай ролик на тему WSL (Windows Subsystem for Linux) - подсистема Linux в Windows. Поставил себе, на первый взляд круто, но я только учусь. Работают ли на ней люди или она только для домашнего пользования подойдёт?

[@Ca1vema]

Работают. VScode умеет в WSL работать. Хотят там проекты, а из под винды запускают VSCode и кодируют.

[@sanic7013]

Молодец, Алексей Голобурдин!

[@isaevalexey7189]

Мне нравились ваши видео. Я считаю - "Данное видео не корректно и не компетентно, видимо записывалось под воздействием эмоций". Около 10 лет не занимался разработкой, сейчас вспоминаю все с азов... Но как 10 лет назад java - была актуальна, так и сейчас в топе. Каждый язык предназначен для своей области применения и хорош по своему.

[@t0digital]

А где я говорю, что джава неактуальна? Тайм код пришлите, пожалуйста, где я это говорю? То, что джава в топе - это не так. Посмотрите график tiobe по java www.tiobe.com/tiobe-index/java/ График на уменьшение. И в целом рейтинг языков на tiobe: www.tiobe.com/tiobe-index/ В топе там Python. Это объективные цифры, не мои фантазии - даже если вы с ними лично не согласны.

[@bobrakaubamha6265]

@@t0digital этот индекс - всего лишь поисковый рейтинг. Не очень представляю, как по нему можно судить о чем-то кроме интереса к языку программирования со стороны Интернета. Интерес к Python объясняется, скорее всего, тем, что с ним сталкиваются не только программисты. Это прикладной язык для анализа данных, его часто используют для обучения основам. Его легко развернуть (anaconda, jupyter) и начать. Инфоцыгане, опять же, славят легкий вход, наплодили кучу "курсов" и раскидали рекламу. Вот язык и в топе.

[@t0digital]

@@bobrakaubamha6265 я не уверен, что курсов по джаве меньше, чем по питону, аналитики у меня нет, а у всех Гб/скилбокс/практикумов/отусов и прочих вполне себе и курсы по джаве, и курсы по питону. Судить о популярности технологии по поисковым запросам можно. Чем люди пользуются, о том и ищут. Если поисковых запросов по Algol86 мало, это вполне себе говорит о том, что Algol86 не так чтобы сильно популярен:)

[@bobrakaubamha6265]

@@t0digital о популярности судить можно. Я, собственно, об этом же говорил. Вот только популярность не свидетельствует ни о качестве, ни о действительной распространенности технологии. Пример - php. Как технология, php стал гораздо лучше, чем был, а популярность снизилась, хотя софта написано много.

[@t0digital]

@@bobrakaubamha6265 ну так я и говорю о популярности=актуальности. Вполне возможно Algol86 на три головы круче джавы, но на нём пишут полтора человека и это стоит иметь в виду.

[@sergeikirjanov7184]

Последний пример: в client.py `from config import container`, a в config.py `register(MailProvider,UnioneProvider)`. Значит для клиента всегда будет ресолвиться Unione. Так же теряется вся суть контейнера. Я бы сделал, чтоб клиент импортил абстрактный конфиг с контейнером, регистрацию UnioneProvider в конкретном конфиге. Тогда main-ов и конкретных конфигов может быть несколько. Или в python-е разные config-и через настройки import-a получаются?

[@КириллЧе-я5ы]

Троллинг зачетный!!

[@KonstantinPrydnikov1]

17:05 Почему мне кажется, что здесь декоратор правильней применять, чем в следующем примере с классами и импортом, который потом поди разберись что там у кого в неявном виде спереди и сзади вытворяет?) И кстати не покидало ощущение что на Алексея направлена пушка черная из CS с глушаком, прям переживал весь эфир. Так вот, к чему я, такая пушка как декоратор в данном случае и должна нам напоминать о функционале аспекта, который за ней стоит, а именно: Пришли за кадром к Алексею и сказали что-нибудь хорошее про Джаву и Мартина расскажешь, а то рейтинги падают? А нет - вот M16. А Алексей...эээ. Вот M16 - это @декоратор, а эфир - то что оборачивается.

[@t0digital]

Явное лучше неявного согласно Zen of Python, с этой точки зрения явный декоратор лучше неявного расколбаса, который где-то навешивается:) С другой стороны логика в этих декораторах (явных или нет) должна быть вспомогательной, и если неявный подход применяется, все разработчики в команде все равно о нем должны знать. Если так, то может и неявное заведение это ок. Пушка да) не нравится эхо на записи, если пушка ближе к источнику звука, эхо меньше пишется

[@w96k]

Спасибо за ролик, интересно Сам Роберт Мартин давно на Clojure пересел и судя по всему любит этот язык программирования. Возможно все эти чистые коды всё-таки из-за невозможности определённые идеи выразить , нежели из-за "правильности" проектирования и т.д. Не хочу говорить, что паттерны сами по себе бесполезны или что-нибудь в этом роде, но их неправильное и(ли) неуместное применение найти довольно просто и они часто усложняют проект без видимого повода. Про Clojure искать: Robert Martin "Why Clojure?"

[@sergeidemianenko2516]

Спасибо, интересная статья

[@indigoram89]

Поправился, пора почаще покидать компьютер и делать кардио 😀

[@t0digital]

Yep:)

[@indigoram89]

@@t0digital это наша общая задача )) кстати, для меня сработала такая фишка, что решил утром первым делом делать тренировку, прямо без размышлений в 9 утра кинул коврик и погнал, потому что иначе, если оставлять на день или на вечер, то НИХРЕНА до тренировки не добираешься )))

[@t0digital]

@@indigoram89 спасибо за мысль, да! Надо надо:)

[@КириллГугл-и3у]

круто, спасибо!

[@k1dglovesk721]

Джава тоже развивается и молодцы, что сделали опен ждк, ну и спринг бут, спринг сделал доступным ejb для масс. Джава рулила, когда делали монолиты многопоточные, джава кластер и тп, сейчас упор на многопроцессность) зачем ловить все эти проблемы с многопоточностью, когда можно размазать по процессам, ну и микросервисы, асинхронность это основное направление высвобождения процессорного времени. Сумбур конечно но как-то так))) P. S. зечем нужно скоростное приложение, которое упрется в ввод/вывод, синхронизацию потоков и упадёт по аут оф мемори))) ну вы понимаете...

[@neko_neko_nyan]

По-моему пример с punq можно сократить до: # config.py MAIL_PROVIDER = UnioneProvider # client.py Mail(config.MAIL_PROVIDER).send(...) Хотя я бы сделал Mail синглетоном, который сам берет провайдера из конфига.

[@r735g3]

Тоже не особо понял в чем смысл контейнера в данном примере. По-моему ничем не отличается от того, чтобы положить нужный нам объект в переменную

[@t0digital]

@@r735g3 punq может резолвить зависимости от зависимостей. Например, MailProvider сам может от чего-то зависеть и все эти зависимости внутри себя разрулит punq. Пример есть в их доке: class ConfigReader: def get_config(self): pass class EnvironmentConfigReader(ConfigReader): def get_config(self): return { "logging": { "level": os.env.get("LOGGING_LEVEL", "debug") }, "greeting": os.env.get("GREETING", "Hello world") } container.register(ConfigReader, EnvironmentConfigReader) class Greeter: def greet(self): pass class ConsoleGreeter(Greeter): def __init__(self, config_reader: ConfigReader): self.config = config_reader.get_config() def greet(self): print(self.config['greeting']) container.register(Greeter, ConsoleGreeter) container.resolve(Greeter).greet() Тут ConsoleGreeter зависит от ConfigReader, и punq сам разрулит эту зависимость.

[@OlViktorovich]

решил отказаться от bootstrap, посидел над javascript неделю и в результате - на чистом javascript и css: аккордеон(или кнопка плавного раскрытия меню) и слайдер с поддержкой touchpad И вы правы: в перечислении используемых технологий проекты теряют модный фреймворк bootstrap

[@qurke5139]

Алексей, а когда будет крупное видео по Python по типу "Типизированный Python"?, очень понравился видос такого типа)

[@t0digital]

Возможно! На какую тему вам бы хотелось:)?

[@КириллЧе-я5ы]

Сталкивался с objectARX под Автокад платформы. Так вот вполне себе на 00х с++ основе с сырыми указателями очень часто к объектам доступ по имени…

[@КириллЧе-я5ы]

Ну просто прописываем по контракту , что безопасность объекта ложится на сам объект. В принципе, раии так работает…

[@КоньЛюдоед-ф6ф]

О большое спасибо)

[@user-13520sdf]

После J2EE и JSP мои знания аббревиатур жабы закончились) забыли главные - JDK и JRE!)

[@t0digital]

точняк:)))

[@bobrakaubamha6265]

Но как только JDK и JRE отпоили валерьянкой и успокоили, в помещение, не заметив на крыльце нервно курящую с обиженным лицом JPA, шумно открыв дверь с ноги, влетели возмущенные JCP и JSR ))

[@ehrstnas]

Пример с hackit - как пример отличный. А в реальной жизни за подобный подход не надо по рукам бить? Кто-то, где-то(очень неявно) пропатчил класс, добавив функциональности. Потом пойди найди такое 🤔

[@t0digital]

Ну вот суть AOP в этом и есть. Именно такая - какая-то падла где-то пропатчила класс и пойди ищи, где это произошло:) Явный декоратор с этой точки зрения лучше. Но тогда надо не забывать его ставить. Один пропущенный декоратор на права доступа может открыть конфиденциальную информацию для сторонних пользователей, например. С другой стороны этот патчинг должен добавлять функционал, не изменять/удалять его. Например, логирование, проверка прав доступа, что-то такое. Если разработчик знает, что на проекте такой подход практикуется, то в целом норм.

[@suhanoves]

@@t0digital пропущенный декоратор на раз выявляется unit тестами, а подобный импорт hackit, который даже не используется в коде, можно будет найти только с помощью дебага, а так фиг поймёшь, откуда там взялось это декорирование.

[@t0digital]

@@suhanoves может да, а может и нет - зависит от реализации и документирования. Что-то неявное-то оно всегда есть. Фреймворк любой - это и есть неявное. Ты опираешься на те конструкции, что предоставил тебе фреймворк. А там проверки внутри разные, помогатели, middlewares те же. Ты отдаешь что-то одно, а одна из middleware это меняет - тоже неявное вроде как, но просто если ты пользуешься фреймворком, то должен об этом знать. Так же и с AOP. Джанговые сигналы - отличный пример неявного.

[@MT-fy9zz]

Позанудствую: вообще говоря, в коде hackit сходу видны как минимум одна ошибка и три потенциальные проблемы. Проблема №1 - его императивность. Как следствие, программисты, которые будут его использовать, вынуждены будут как-то гарантировать, что нигде выше до наложения wrapper'а не происходит никаких вызовов foo() у созданных ранее объектов Something - иначе эти вызовы просто не попадут под правильное 'before...after" обрамление. Проблема №2 - его неизбирательность, т.к. обертка "before...after" накладывается без разбора на абсолютно все методы класса Something (даже питоновские псевдо-приватные, с двойным подчеркиванием). И более-менее без граблей эта проблема решается только через родные питоновские декораторы - любая попытка впихнуть какой-то анализ в тело цикла будет означать, что Something начнет зависеть от кода снаружи и программисты почти гарантированно огребут проблем при дальнейшей поддержке. Проблема №3 - его привязка к конкретному классу, существующему в момент наложения wrapper'а. Потомки этого класса им будут полностью проигнорированы, если только в их методах явным образом не вызовут super(). Причем насколько мне помнится (могу ошибаться), питоновские @ декораторы тоже имеют эту проблему - их нужно явным образом указывать у всех потомков, иначе они не работают. Ошибку называть не буду, пусть читающий это найдет ее сам, если ему будет интересно. Скажу только, что ноги у нее растут напрямую из проблемы №2 :)

[@t0digital]

hackit это минимальный пример, демонстрирующий принцип, а не финальная реализация, готовая к тому, чтобы пойти в продакшн. Конечно, должен быть реализован гибкий декларативный механизм регистрации такого поведения, в духе: Aspecter.register(in_objects=(Something,), name_pattern=""^fo"", pre_function=log_before, post_function=log_after) Конечно, регистрация такой сквозной логики должна происходить где-то наверху при инициализации - задолго до реального вызова Something и других аналогичных классов. Мне было важно показать принцип того, как можно навесить вспомогательную логику на уже имеющуюся бизнес-логику без правки этой бизнес-логики, а не писать полный готовый к продакшн пример.

[@uicodeuz]

Кайф

[@sergeikirjanov7184]

Можно и просто конфиг-файл, но тогда мысли такие: - хотим обеспечить переключение разных конфиг-файлов - хотим обеспечить подключение разных конфиг-файлов одновременно, в пределах интерпретатора - не хотим дублировать import парным присвоением, значит переносим присвоение внутрь импортируемой части - хотим отследить конфликтующие присвоения - хотим отследить обращения до присвоения Я сам в python DI не использовал. Там, где я использовал: - в репозитории тысячи файлов и десятки конфигураций - строгая статическая типизация - аннотирую конструкторы классов, ставлю типы аргументов; эти конструкторы руками не вызываю; DI сам создает граф объектов

[@abdulgoniyfarhodov]

когда выйдет продолжение вашего курса "Основы компьютерных веб технологий" ?

[@t0digital]

Следите за обновлениями. Возможно уже в декабре

[@abdulgoniyfarhodov]

@@t0digital Отлично

[@КузнецовДмитрий-м6э]

А вы у себя в команде этот punq где-то в боевом коде используете?

[@t0digital]

пока нет

[@gaponukz]

@@t0digitalКак справляетесь с зависимостями? Хотелось бы видео об этом с примерами)

[@korolcreeper]

В названии "АОП в Python vs JAVA" Но в примерах кода и в объяснении только питон, странно.

[@WarlikeLaux]

Вход в клуб 1500 рублей или это подписка с оплатой раз в месяц?

[@t0digital]

Подписка. Примерно по книге в месяц будем читать. 18 декабря новая книга.

[@КириллЧе-я5ы]

Ну декоратор - просто паттерн обертки, который не несёт в себе ничего сложно-заумного - простейший паттерн из граспа…

[@crypto_octocat]

Кто поставляет инструменты для энтерпрайза? И что это за инструменты?

[@galua]

J2EE тулзы разрабатывает Eclipse Foundation. Spring поставляют Pivotal.

[@t0digital]

@@galua и многое платное от Oracle. Во всяком случае в мои времена так было, вероятно в больших интеграторах по-прежнему

[@galua]

@@t0digital на данный момент Oracle барыжат своей JDK, которую они сделали платной. Хотя непонятно кто это покупает, когда есть бесплатные JDK куда лучше. Плюс Oracle в саппорт своей БД ушли. Сейчас это их основное направление продаж. К J2EE (Jakarta) они уже почти никакого отношения не имеют.

[@t0digital]

@@galua мне кажется они столько своего напродавали, что это не умерло так быстро. Webcenter, ADF их, интегрированные ECM, BPM и тп. Но хз. В России понятно, что каюк этому всему уже)

[@antonkor8128]

Что с нумерацией строк в nvim???

[@t0digital]

relative numbers, показывают на сколько строк вверх или вниз надо сдвинуться, чтобы попасть на конкретную строку. Хотя я не могу сказать, что я к этому привык и передвигаюсь по привычке на глаз, не смотря на эти номера)

[@trankov]

Всё равно не понимаю, когда и зачем может понадобиться DI в Python. Вот в FastAPI, например, много DI. И зачем это там?

[@t0digital]

DI в питоне и в других ЯП выполняет одни и те же задачи, позволяет изменять поведение класса без изменения самого класса и упрощает юнит тестирование заменой реального внедряемого объекта его простенькой тестовой копией. DI возможен и без контейнера специализированного

[@trankov]

@@t0digital но в Python мы можем достичь этого и без DI. Внешнее управление зависимостями, в целом, подход местами незаменимый, особенно если у нас что-то вроде конечных автоматов или всякой другой сложной бизнес-логики. Но, например, ваш пример из видео проще и логчнее решить через миксин-наследование.

[@MT-fy9zz]

@@trankov Если mixin у вас является базовым для сотни разных наследников, то при его замене вам в любом случае придется изменить их декларацию в сотне разных мест, тщательно стараясь при этом ни одного не забыть, чтоб не оставить случайно этому классу предыдущее поведение. В случае DI вы просто меняете одну строчку в объявлении бина - и всё, в общем случае абсолютно все использующие его участки кода получают новую реализацию. Бывают, конечно, всякие извращенные ситуации - например, когда часть классов должны использовать старую версию, часть новую, а часть сразу обе. Но в этих случаях с mixin'ами все будет, скорее всего, даже еще запутаннее.

[@trankov]

@@MT-fy9zz звучит очень убедительно, но явно где-то подвох) надо подумать. Спасибо за понятный ответ.

[@t0digital]

Как мы в питоне можем достичь этого без DI? Я не о DI-контейнере, я а самом DI. Наследование почти всегда зло, композиция лучше наследования, композиция это как раз про DI. Наследование это часто попытки наследовать кролика от вертолёта, чтобы переиспользовать что-то от вертолёта в кролике. Композиция это, например, передача нужного функционала вертолёта в конструктор или какой-то setter кролика. Легче тестировать, нет логических проблем с тем, что кролик не является вертолётом

[@vr29645]

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

[@t0digital]

Большое спасибо за комментарий, пошел думать-читать

[@koev1]

Кажется, пример DI можно сделать с помощью функции partial()

[@vinograd11]

А чей-то за место такое?

[@t0digital]

Специальное такое:)

[@_balancy_]

дом Алексея видимо. Пора хаус-тур видео сделать)

[@Igran4Real]

Недавно видел легаси код на питоне с классом на 2000 строк... Было страшно

[@t0digital]

понимаю:) класс на 2к строк в любом ЯП это страшно

[@Ca1vema]

у нас в легаси проекте код с классом на 27 тысяч строк и методами по 1-3к Здоровья вам Игорь.

[@Igran4Real]

@@Ca1vema и я вам сочувствую. Благо мне ток показали чужой легаси. Мне его не править. Мой легаси полегче успешно переписываю на fastapi)

[@robbarret9568]

Что такое fn?

[@t0digital]

где?

[@tymur.berezhnoi]

Спасибо, хороший контент, но когда автор говорит в начале видео о java enterprise подход и то куда java ушла - это совсем абстрактно, не понятно так как нет деталей и ничего не имеет общего с тем, что действительно происходить в "мире" java. Автор не раскрыл почему java "ушла не туда". Да и что такое java enterprise?! Есть условно старые проекты использующие старые подходы и технологии - и это боль, а есть множество новых проектов с новыми версиями java, фреймворками и подходами. Более того, коммерческие проекты не пишутся на "голом" языке, многое решает фреймворк, #1 для java - это spring boot. EJB, JSP, JNI, J2EEВ, JAAS... - не понятно зачем было упоминать все эти аббревиатуры?! Автор, наверное, не знает, что все это достаточно устарело и в современных проектах не используется, только в legacy проектах... Уже многие годы java разработчику не нужно знать что такое jsp и прочие, мы просто берем java + spring boot и делаем свою работу: реализуем бизнес логику, пишем сервисы, контроллеры, модели - все тоже самое что и на других современных языках и фреймворках, абсолютно не вникая JTA, JFC, JNI (вообще не понятно каким боком это тут)... Вся экосистема java делает тоже самое что и другие - упрощает все что можно упростить для разработчиков: упрощается синтаксис языка, появляются новые синтаксические возможности, очень активно развивается JVM, GraalVM, project loom, native images и еще много чего другого, возможно, автор этого не знает. "...не все джависты знают АОП и не смогу разложить..." - чистой воды нарратив, очень даже знаем, я не встречал джависта который этого не знает... В Java (без фреймворков) нет на столько простого способа как в python работать с АОП, да и еще что бы в декларативном подходе, в Java императивный подход работы с АОП и дело совсем не в том скриптовый язык java или нет... Создается впечатление, что автор создает нарратив, но за видео спасибо.

[@СтаниславРодин-г6ю]

Боже!? Я Python то учу 3 месяца, зачем я это посмотрел ?)))

[@galua]

Никто сейчас на J2EE не пишет. Если только это саппорт доисторического проекта. Все джависты перешли на Spring Boot. Там свой мир. Куда более радужный

[@t0digital]

без километровых XML:)?

[@galua]

@@t0digital естественно. XML-конфиг теперь это моветон. Позови в видос, расскажу :)

[@t0digital]

@@galua помню как лет 10 назад один парень из нашего отдела, где я работал, предлагал затащить спринг в проект и старожилы говорили ну нэээт ты штооо:) должно быть, сейчас этот парень счастлив:)

[@galua]

@@t0digital нормальным Spring стал в 2013, когда появился Spring Boot. А сам по себе Spring - это просто DI-контейнер. Ещё был Spring MVC (до сих пор есть), но про это я вспоминать не хочу) А парня не зря старожилы отговаривали. 10 лет назад захлебнулись бы.

[@ilyaalexful]

Ещё как пишут. Тащат старый j2ee дальше и дальше. Привет продуктам IBM. Стандарт xml и soap живут в корпоративных системах и изжить это невозможно.

[@-boiadeiro-]

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

[@t0digital]

Это на батхёрт. Я спокойно отношусь ко всем ЯП. Писал на Java, работал в Oracle. Везде есть минусы, в питоне в том числе. Километровые XML конфиги это не есть хорошо в любом случае. Хотя судя по всему современная java уже отошла от них. Но не думаю, что далеко, DNA уже такой)

[@antondoronin1261]

@@t0digital ну тут как посмотреть: энтерпрайз не слишком-то податлив, поэтому новые версии языка крайне медленно адаптируются, но этих версий клепают сейчас по две в год. Только и успеваем облизываться на новый синтаксис и фичи

[@aliasSan2828]

@@antondoronin1261 Вопрос в том, что реально дает этот синтаксис? Нам, разрабам то, понятно хочется свежей струи, чего то новенького так сказать. Я только за. Но если смотреть по сути, не обрастет ли тот же Питон тоннами фреймворков и библиотек с разными акронимами, если займет место Джавы? И насколько будет просто поддерживать, именно поддерживать это все долгие годы. Пока что это java в основном. Питон пока видится больше как специфический DSL, для определенных областей. На котором можно например написать специфические сервисы, за счет наличия большого кол-ва специфических библиотек. Тот же AI. Как возможность катать какой то тулинг для разработки и администрирования. Например Си/Си++ так и не ушел окончательно из профессиональных десктопных инструментов, как его не пытаются подвинуть. Обычно все самое вкусное, ну или большинство, скажем так, до сих пор написано на этом языке. Наоборот, есть десктопные приложения которые пытались, и даже в нечто выросли, но так в итоге застряли как некая нишевая альтернатива, которой кто то время от времени пользуется. (Если смотреть на мейнстрим то толковых контрпримеров единицы. У меня на уме только IDEA да VS Code. Но тут у многих людей начинаются претензии к потребляемым ресурсам. Я уже не говорю за такие вещи как 3D и 2D редакторы какие то, игровые движки). Поэтому и с джавой будет так же. Кстати, вот писать энтерпрайз на Си++, по рассказам очевидца, то еще веселье. Тем более говорят есть места на этой планете, где до сих пор люди пользуются и поддерживают программы на COBOL. А мы джаву тут решили уже списать, со счетов ))) В общем это заблуждение считать что синтаксис все решает. Есть дофига еще важных моментов, которые должны быть обеспеченны, чтобы технология виделась надежной, не сильно рискованной, с хорошей поддержкой на долгие годы и было желание вкладывать огромные бабки, не беспокоясь что завтра они превратятся в тыкву. А с другой стороны это инертность, когда надежный инструмент и технологии есть, пусть и с какими то проблемками больше внутреннего характера. Тем более попа боль по поводу отсутствия какого то синтаксиса переживает не бизнес. PS: Кстати, да тоже хотел сказать, что современный энтерпрайз это уже далеко не J2EE. Есть аннотации, есть как минимум спринг контейнер, есть суппорт многих вещей надежными командами, что снимает нагрузку с разрабов бизнес апликейшена, а это немаловажно. А ошибки, так они везде есть, это же не потому что акронимов много. А вообще растет из нижних слоев, например таких как прямая работа с памятью и арифметика указателей в библиотеках Cи рантайма, на котором написано большинство современных языков и виртуальных машин, если не все так или иначе. В этом смысле джава вряд ли позволяет больше чем может позволить сишная либа под капотом. Питон тоже активно юзает сишный слой, всякие байндинги там. И я думаю что в нем тоже что то будет находится.

[@universeunity9970]

@@t0digital Километровые xml сейчас уже никто не пишет)

[@t0digital]

@@universeunity9970 прям никто? Прям спрашивали? Прям точно)? Даже если API системы, с которой вы интегрируетесь, принимает километровые XML? Вы такие встаёте, топаете ногой и громко говорите - никто сейчас не пишет километровые XML! А потом садитесь и пишете его:)

[@sanchey92]

Бросьте зантматься ерундой и пишите на шарпике. И сладко и строго и быстро)

[@ДанилТахтаров-п8д]

Пример с mail, это паттерн стратегия в чистом виде :)

[@cs_dequeue]

тема хорошая, но почему нельзя просто через дикт решать dependency inversion? container = {"provider": UnioneProvider} ... foo(provider=container["provider"] интересен ответ в пользу punq)

[@okopyl]

А зачем DI контейнер?) Чем плохо решение с конфиг/инит-файлом, в котором прописываются все зависимости тупо через переменную типа mail_provider = MailgunProvider, а уже где нам нужно его использовать, то просто делаем импорт этой переменной из конфиг-файла. Абсолютно не понимаю что тут можно было на 500 строчек писать) Лишние обертки чтобы куда-то завернуть переменную, а потом её каким-то хитро-вывернутым способом получить?)

[@sergzach]

Привет! Как насчёт того, что без ООП - люди пишут огромный повторяющийся код, и при росте проекта - лучше бы было ООП "со всеми сложностями"?

[@t0digital]

Можно писать хорошо и без ООП, можно писать плохо и с ООП, да и ООП бывает разным, в go/rust нет наследования, но есть объекты, является ли это ООП? С какой-то точки зрения да, с какой-то - нет, однако сразу все эти классические фентифлюшки с наследованием идут лесом)

[@sergzach]

@@t0digital Наследование стоит использовать только в крайнем случае, полагаю, это нормально. Плохо с ООП - это не ООП, в строгом смысле.

[@sergzach]

@@t0digital Нет, нпличие объектов - не гарантирует ООП в современном понимании.

[@t0digital]

@@sergzach ну значит в двух популярных современных ЯП осознанно нет ООП и это прекрасно.

[@sergzach]

@@t0digital Ничего хорошего. Пишут тут, понимаешь, много кода безо всякой системы, посмотришь на это - задачи не хочется брать, до того все нестройно.

[@programisli]

Ох мне кажется ты рискуешь опять говорить на такие опасные темы. Любители Java могут накидать...

[@t0digital]

Да, понимаю:) Но я вроде мягенько, только на основе своего опыта и Чистого кода. Сейчас, пишут тут в комментах, километровые XML конфиги в Java уже моветон, J2EE убит, а Spring конфетка. Проверять я это, правда, не хочу:)

[@tiy2000]

@@t0digital а зря "не хочешь проверять". Spring boot реально изменил подходы))