что есть ни что иное, как switch с паттерн-матчингом (если бы исходники спринга кто-нибудь решился переписать на яву версии больше 17) и чем вы наверняка пользуетесь в своих проектах на спринге а вы мне скажите, что авторы спринга "не умеют в полиморфизм" и не знают про solid
хотите я покажу использование break (label) в коде JDK? ) или использование switch тоже в коде JDK?
давайте еще раз попробую свою мысль озвучить: switch - это оператор языка. он не имеет никакого отношения к дизайну структуры классов. он присутствует во многих объектно-ориентированных языках. он есть в C#, Go, Kotlin, Rust и много где еще. вы беретесь утверждать, что понимаете ООП лучше, чем дизайнеры C#, Go, Kotlin или Rust, которые изначально создавались как ООП языки?
я не понимаю аргументов в стиле "switch нарушает open/close принцип". это нонсенс! оператор языка не может нарушать правила дизайна структуры классов!
я готов поверить, что вы встречались с кодом, где оператор switch использовался не правильно. но и кухонные ножи, знаете ли, бывает используют не по назначению. разве это повод запрещать кухонные ножи?
и еще мне хочется развить вашу мысль: предлагаю убрать "else if" в частности и "else" вообще, так как, во-первых, без них можно обойтись, а во-вторых, это "очевиднейший bad smell"(тм)
но у вас нет аргументов против, кроме "это очевиднейший bad smell". почему он "очевиднейший", кому "очевиднейший", почему это вообще "bad smell" - не понятно. но давайте попробуем так: switch в коде - это очевиднейший good taste. оппонируйте!
И правильно ли я понимаю, что в вашей системе вполне допускается одновременное выполнение одной и той же задачи несколькими инстансами (но без тайм-аут исключения доработает только 1 или 0 задач)? То есть, если выполнение задачи на одном инстансе вышло за таймаут, но исключение еще не было выброшено, то другой инстанс вполне может начать выполнять ту же самую задачу?
Можно сделать удобную реализацию, чтобы thread local timeout автоматически учитывался во всех клиентах и jdbcTemplate.
А как у вас это реализовано? Учесть таймаут из thread-local можно либо постоянно (в цикле) проверяя, не вышли ли мы за лимит, либо проверить, сколько выполнялся код после того, как он, собственно, выполнился. Но тогда получается, что задача будет выполнена, а потом выброшено исключение (так как выполнение вышло за лимит). То есть, есть высокая вероятность того, что одна и та же задача будет выполнена много-много раз, но ни разу успешно.
кажется, что это самая интересная часть реализации, которую вы почему-то пропустили. Если у яндекса найдутся силы и время, чтобы выделить ThreadLocalTimeout в библиотеку, которая бы легко интегрировалась с ThreadPoolExecutors и имела расширения для интеграции с наиболее часто используемыми http-clients, и spring-data-commons, то это был бы однозначно плюсик в "карму"!
если устанавливаете concurrency = 1, то и prefetch_count можно спокойно поставить в 1 или уже использовать kafka у которой очередность сообщений внутри партиции гарантирована "с рождения".
но вообще, про concurrency - это очень ценное замечание! мало кто читает документацию внимательно, но зато потом удивляются "у меня же очередь! почему у меня сообщения обрабатываются не в том порядке, в котором я их записал?!"
Это data transfer object - т.е. простой класс для передачи данных. То, что вы описали идет в разрез с best practices.
Покажите пожалуйста эти best practices! DTO вовсе не обязаны буть анемичными и, уж точно, анемичные dto - это не best practices, а просто один из подходов. причем, весьма спорный.
данные должны валидироваться ДО создания dto
Вот это я не понял. Валидируем мы обычно входящие данные. Как вы собрались что-то валидировать ДО создания dto? Нет, ну возможно, конечно, в самой json-схеме прописать соответствующие проверки (у вас в статье, кстати, об этом ни слова) и окончательно превратить все в реинкарнацию jaxb, но, кажется, цель была не в этом. Ну и json-схема с валидациями сразу становится монструозной и отвратительно читаемой. Примерно как xsd. Для которой в итоге пришлось писать отдельные инструменты для редактирования. И это вполне себе относится к следующему аргументу
При просмотре пулл реквестов на много удобнее отслеживать изменения в схеме,
нет. не проще. читать код все давно привыкли. читать язык описания json-схемы - надо привыкать, схема (с валидациями) занимает много экранов и инструментов для удобной работы с json-схемой пока не завезли.
кстати, предлагаю вам почитать о том, почему в свое время все устали работать с xsd-схемами и оценить, все ли старые "болячки" решены в json-схеме
я все еще не понимаю, зачем вам схема и зачем генерировать dto-шки каждый раз при пересборке проекта?
Если вам внешний сервис выдал схему, то да, можно 1 раз сгенерировать dto и положить в исходники. плагин не нужен.
если вам внешний сервис схемы не дал, то по json-у можно сразу сгенерировать dto-шки, минуя схему.
если вы хотите облегчить жизнь тем, кто будет интегрироваться с вашим сервисом, то тут схема, безусловно, поможет. Но зачем в этом случае плагин?
ну, ок. я могу придумать 1 вариант, когда это может быть полезно. в случае, когда вы выкладываете схему в качестве "документации" к своему сервису, то перегенерация не даст вам забыть поправить собственные dto-шки при изменении файла со схемой. наверное, единственный полезный вариант использования этого плагина.
но даже в этом случае, я бы генерировал схему по dto-шкам, а не наоборот.
еще мне кажется, что вы как-то пренебрежительно относитесь к dto. не нужно их скрывать!
это полноценные классы проекта.
их можно (и нужно) обвесить аннотациями для валидатора, в них можно (и нужно) писать трасформирующие/аггрегирующие методы, работающие с полями dto, в них можно(и нужно) реализовывать бизнес логику, основанную на полях этого dto.
А чем файл со схемой отличается от одного большого класса с кучей вложенный классов-dto'шек? Ну кроме того, что dto'шки пишутся на привычной java, а язык описания схемы еще нужно освоить. Кроме того, в dto'шках могут быть удобные методы для работы со свойствами, а в схеме - нет.
Я понимаю, схема удобна в качестве способа публикации API сервиса, но и в этом случае достаточно сгенерировать dto'шки 1 раз и положить их в исходниики.
Какой выигрыш вы получаете постоянно перегенерируя dto'шки по схеме при каждой сборке проекта?
Нет никакой проблемы создать более 10К тредов на достаточно "средней" современной серверной машинке. Немного возни с конфигами операционки, конфигами JVM, и все создастся.
Причем, вам надо 10К тредов в классическом подходе поток-на-запрос только для случая, когда у вас на одном хосте нужно обслужить 10К запросов одновременно. Либо, у вас есть 10К постоянно открытых соединений.
Эту "проблему" давно научились решать с помощью дополнительных хостов, балансировщика нагрузки и уличной магии.
Реактивное программирование - это вообще не про решение проблемы 10К. "проблема" 10К - жалкий частный случай, который просто удобно показывать в презенташках.
И green thread тоже не про решение проблемы 10К. В конце концов, даже с green threads вы упретесь в ограничение количества локальных портов в системе (если ваш хост не торчит напрямую в интернет), а там порядок даже тот же.
не совсем понятно, почему про explicit локи написано "этот механизм лучше не использовать совсем". это стандартный механизм работы с блокировками в Postgres. Им очень даже можно пользоваться, когда нужно. Как и любым другим инструментом, блокировками нужно уметь пользоваться. Про устройство блокировок в Postgres и работу с ними есть прекрасный цикл статей @erogov(начиная с этой: https://habr.com/ru/company/postgrespro/blog/462877/)
в плюсы коллекции завезли даже «чуточку» раньше, чем в яву )
но как-то так сложилось, что задачи уровня senior — это про то, когда стандартных библиотечных структур уже не хватает и надо писать свои
а там как раз и работа с массивами, и «нестандартная» работа с примитивами, и вот это вот все про «а без выделения дополнительной памяти сможете?»
Попробуйте и вы выполнять работу и не получать зарплату. Уверяю, вы будете шокированы. Еще сильнее вы будете шокированы, если попробуете предложить работу, но не зарплату не-россиянам.
еще давайте я покажу это
https://github.com/spring-projects/spring-framework/blob/1af64802174c0122b59a2178f17f8f1d2b4cbcd4/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/annotation/ResponseEntityExceptionHandler.java#L143
что есть ни что иное, как switch с паттерн-матчингом (если бы исходники спринга кто-нибудь решился переписать на яву версии больше 17) и чем вы наверняка пользуетесь в своих проектах на спринге
а вы мне скажите, что авторы спринга "не умеют в полиморфизм" и не знают про solid
хотите я покажу использование break (label) в коде JDK? )
или использование switch тоже в коде JDK?
давайте еще раз попробую свою мысль озвучить: switch - это оператор языка.
он не имеет никакого отношения к дизайну структуры классов.
он присутствует во многих объектно-ориентированных языках.
он есть в C#, Go, Kotlin, Rust и много где еще.
вы беретесь утверждать, что понимаете ООП лучше, чем дизайнеры C#, Go, Kotlin или Rust, которые изначально создавались как ООП языки?
я не понимаю аргументов в стиле "switch нарушает open/close принцип".
это нонсенс!
оператор языка не может нарушать правила дизайна структуры классов!
я готов поверить, что вы встречались с кодом, где оператор switch использовался не правильно.
но и кухонные ножи, знаете ли, бывает используют не по назначению.
разве это повод запрещать кухонные ножи?
пока вижу лишь голословные утверждения.
нет, не нарушает.
нет, не усложняет.
все, что вы описали - это вопросы дизайна структуры классов, которые не имеют отношения к оператору языка.
можно ли использовать оператор не корректно и нарушить общепринятые принципы дизайна?
да, можно.
вот только, при чем тут сам оператор языка?
и еще мне хочется развить вашу мысль: предлагаю убрать "else if" в частности и "else" вообще, так как, во-первых, без них можно обойтись, а во-вторых, это "очевиднейший bad smell"(тм)
но у вас нет аргументов против, кроме "это очевиднейший bad smell". почему он "очевиднейший", кому "очевиднейший", почему это вообще "bad smell" - не понятно.
но давайте попробуем так: switch в коде - это очевиднейший good taste.
оппонируйте!
И правильно ли я понимаю, что в вашей системе вполне допускается одновременное выполнение одной и той же задачи несколькими инстансами (но без тайм-аут исключения доработает только 1 или 0 задач)?
То есть, если выполнение задачи на одном инстансе вышло за таймаут, но исключение еще не было выброшено, то другой инстанс вполне может начать выполнять ту же самую задачу?
А как у вас это реализовано? Учесть таймаут из thread-local можно либо постоянно (в цикле) проверяя, не вышли ли мы за лимит, либо проверить, сколько выполнялся код после того, как он, собственно, выполнился. Но тогда получается, что задача будет выполнена, а потом выброшено исключение (так как выполнение вышло за лимит). То есть, есть высокая вероятность того, что одна и та же задача будет выполнена много-много раз, но ни разу успешно.
кажется, что это самая интересная часть реализации, которую вы почему-то пропустили. Если у яндекса найдутся силы и время, чтобы выделить
ThreadLocalTimeoutв библиотеку, которая бы легко интегрировалась с ThreadPoolExecutors и имела расширения для интеграции с наиболее часто используемыми http-clients, и spring-data-commons, то это был бы однозначно плюсик в "карму"!если устанавливаете concurrency = 1, то и prefetch_count можно спокойно поставить в 1
или уже использовать kafka у которой очередность сообщений внутри партиции гарантирована "с рождения".
но вообще, про concurrency - это очень ценное замечание!
мало кто читает документацию внимательно, но зато потом удивляются "у меня же очередь! почему у меня сообщения обрабатываются не в том порядке, в котором я их записал?!"
нет. возвращаемся к заявлению в "первый отдел" для обновления версии библиотеки. и, конечно, это все "ради вашей же безопастности"
Покажите пожалуйста эти best practices! DTO вовсе не обязаны буть анемичными и, уж точно, анемичные dto - это не best practices, а просто один из подходов. причем, весьма спорный.
Вот это я не понял. Валидируем мы обычно входящие данные. Как вы собрались что-то валидировать ДО создания dto?
Нет, ну возможно, конечно, в самой json-схеме прописать соответствующие проверки (у вас в статье, кстати, об этом ни слова) и окончательно превратить все в реинкарнацию jaxb, но, кажется, цель была не в этом.
Ну и json-схема с валидациями сразу становится монструозной и отвратительно читаемой. Примерно как xsd. Для которой в итоге пришлось писать отдельные инструменты для редактирования.
И это вполне себе относится к следующему аргументу
нет. не проще. читать код все давно привыкли. читать язык описания json-схемы - надо привыкать, схема (с валидациями) занимает много экранов и инструментов для удобной работы с json-схемой пока не завезли.
кстати, предлагаю вам почитать о том, почему в свое время все устали работать с xsd-схемами и оценить, все ли старые "болячки" решены в json-схеме
del
я все еще не понимаю, зачем вам схема и зачем генерировать dto-шки каждый раз при пересборке проекта?
Если вам внешний сервис выдал схему, то да, можно 1 раз сгенерировать dto и положить в исходники. плагин не нужен.
если вам внешний сервис схемы не дал, то по json-у можно сразу сгенерировать dto-шки, минуя схему.
если вы хотите облегчить жизнь тем, кто будет интегрироваться с вашим сервисом, то тут схема, безусловно, поможет. Но зачем в этом случае плагин?
ну, ок. я могу придумать 1 вариант, когда это может быть полезно.
в случае, когда вы выкладываете схему в качестве "документации" к своему сервису, то перегенерация не даст вам забыть поправить собственные dto-шки при изменении файла со схемой.
наверное, единственный полезный вариант использования этого плагина.
но даже в этом случае, я бы генерировал схему по dto-шкам, а не наоборот.
еще мне кажется, что вы как-то пренебрежительно относитесь к dto.
не нужно их скрывать!
это полноценные классы проекта.
их можно (и нужно) обвесить аннотациями для валидатора, в них можно (и нужно) писать трасформирующие/аггрегирующие методы, работающие с полями dto, в них можно(и нужно) реализовывать бизнес логику, основанную на полях этого dto.
А чем файл со схемой отличается от одного большого класса с кучей вложенный классов-dto'шек?
Ну кроме того, что dto'шки пишутся на привычной java, а язык описания схемы еще нужно освоить.
Кроме того, в dto'шках могут быть удобные методы для работы со свойствами, а в схеме - нет.
Я понимаю, схема удобна в качестве способа публикации API сервиса, но и в этом случае достаточно сгенерировать dto'шки 1 раз и положить их в исходниики.
Какой выигрыш вы получаете постоянно перегенерируя dto'шки по схеме при каждой сборке проекта?
рискну предположить, что деньги-то как раз у Альфы есть. но! лицензию им сейчас никто просто не продаст.
Нет никакой проблемы создать более 10К тредов на достаточно "средней" современной серверной машинке.
Немного возни с конфигами операционки, конфигами JVM, и все создастся.
Причем, вам надо 10К тредов в классическом подходе поток-на-запрос только для случая, когда у вас на одном хосте нужно обслужить 10К запросов одновременно. Либо, у вас есть 10К постоянно открытых соединений.
Эту "проблему" давно научились решать с помощью дополнительных хостов, балансировщика нагрузки и уличной магии.
Реактивное программирование - это вообще не про решение проблемы 10К.
"проблема" 10К - жалкий частный случай, который просто удобно показывать в презенташках.
И green thread тоже не про решение проблемы 10К.
В конце концов, даже с green threads вы упретесь в ограничение количества локальных портов в системе (если ваш хост не торчит напрямую в интернет), а там порядок даже тот же.
не совсем понятно, почему про explicit локи написано "этот механизм лучше не использовать совсем".
это стандартный механизм работы с блокировками в Postgres. Им очень даже можно пользоваться, когда нужно.
Как и любым другим инструментом, блокировками нужно уметь пользоваться.
Про устройство блокировок в Postgres и работу с ними есть прекрасный цикл статей @erogov(начиная с этой: https://habr.com/ru/company/postgrespro/blog/462877/)
но как-то так сложилось, что задачи уровня senior — это про то, когда стандартных библиотечных структур уже не хватает и надо писать свои
а там как раз и работа с массивами, и «нестандартная» работа с примитивами, и вот это вот все про «а без выделения дополнительной памяти сможете?»
Попробуйте и вы выполнять работу и не получать зарплату. Уверяю, вы будете шокированы.
Еще сильнее вы будете шокированы, если попробуете предложить работу, но не зарплату не-россиянам.