но если развить этот пример, то альтернативным решением может быть придумать нормальный тип вместо Optional<Map<String, List<Object>>>, что сделает контракт метода не отвратительным, а не просто заметать под var
Спасибо за конструктивный коммент. То, что под капотом динамики нет, я осведомлен) Видимо фраза "привнести динамики" оказалась слишком абстрактной. Под ней я как раз имел ввиду некоторые заимствования из динамических языков.
Если я все нашел правильно, 1. Первый динамический язык LISP появился в 1958 году. 2. Первый статический язык с выведением типов Meta Language появился в 1973
Но вот чем именно вдохновлялись разработчики определенных языков, наверняка уже не узнать, к сожалению, или к счастью)
Но брать и заменять везде явное указание типа на var только потому что это теперь компилируется, это идея, которая больно аукнется
Предложение звучит полностью так. Сам по себе var не плохой. Плохая идея использовать его бездумно везде. Как это аукнется: Меньше контроля за контрактами. За счет того что типы скрыты, на возникает меньше поводов задуматься о правильности контрактов и композиции. В своей практике часто замечал проблемы в коде, именно когда на глаза попадался сомнительный тип переменной в контексте метода. + Общее замедление ревью
В статье нигде и не написано, что java стала динамическим языком от этого. Но фишка с выведением типов появилась, потому что опыт динамических языков показал, что так писать может быть удобно в некоторых случаях. По этому подобный сахар принесли во многие статические языки.
Так я и не говорю, что неявные типы это плохо. Я говорю о том, что нужно позаботиться о том, чтобы код было удобно читать. Иногда удобно записать все в одну строку и опустить типы, иногда необходимо явно подсветить какой тип у нас есть на определенном этапе.
С появлением var перед разработчиком вариативности как писать стало больше. Мое мнение, что писать везде var вместо полноценного типа только потому, что так позволяет компилятор и это короче - не верно.
"в статически типизированные языки пытаются привнести динамики", фраза написана так. я не говорю что java становится от наличия var динамически типизированным языком.
Но этот синтаксический сахар в работу с java привносит одну особенность из динамических языков. Если я объявил переменную, я могу менять ее значение при рефакторинге на любой тип, не меня объявление переменной. Либо просто не задумываться о типе переменной при ее создании.
В java так изначально не было. Подсмотрели это в динамических языках.
Не, ни в коем случае я этого не пытаюсь сделать, задача NotificztionService соединить запрос с ответом и отдать событие о том, что ответ получен сервисуу который генерировал запрос. В нашем случае AuthService, а уже его задача принять решение о разлогине.
Согласен что в примере не однозначно отразил идею, подумаю как скорректировать. Хотя я явно прописал, что в NotificationService нельзя явно вызывать логику разлогина
Да, физически это 2 отдельных потока, но в этом и смысл дизайна, чтобы не обременять AuthService особенностями физики, а дать понятную абстракцию "запрос-ответ-реакция". Вы же если в магазине заказываете товар которого нет в наличии приходите забирать его в этот же магазин, а не едете на склад. Да, поездка на склад вполне рабочий вариант, но будет не очень удобно
Принципиально новая логика, потому что это интеграционное взаимодействие, в рамках которого нужно тянуть данные с почтового ящика. Это полноценная отдельная сложная работа, которую нельзя просто так вмазать в то что уже есть, нужно изолировать.
Привычно и логично, потому что по своей сути это вызов функции с возвращаемым значением, и хотелось бы чтобы это так и выглядело (как вызов метода, для этого и был дан "рецепт 2"), независимо от того как оно устроено внутри. Не должно быть распадания на 2 независимых потока (исходящий и входящий).
NotificationResponseListener не имеет полномочий принимать решение о том что нужно разлогинить, это ответственность AuthService. NotificationResponseListener только обеспечивает входной трафик, не вдаваясь в суть входящих сообщений.
Потому что репозиторий как правило предполагает долговременное хранение с целью обмена, а кэш это как раз временное хранилище для оптимизации взаимодействия с целевым хранилищем
По поводу репозитория вы правы, но пример был про то, что явно прописанная аннотация Transactional в примере не окажет влияния на границы транзакции. Пример и разбор скорректировал, чтобы снизить вероятность разночтения. Спасибо за замечание)
Спасибо за поддержку и локализацию ошибки в формулировке)
Очень приятно, что вы увидели мой посыл и не побоялись словить минус за коммент.
P.S. большинство оплевух было поделу, но именно ваш коммент вернул мне мотивацию,
Надеюсь, что следующая статья будет менее противоречивой)
все так)
я и не призываю отказывать от var,
но если развить этот пример, то альтернативным решением может быть придумать нормальный тип вместо Optional<Map<String, List<Object>>>, что сделает контракт метода не отвратительным, а не просто заметать под var
вся статья исключительно про эту идею
Спасибо за конструктивный коммент.
То, что под капотом динамики нет, я осведомлен)
Видимо фраза "привнести динамики" оказалась слишком абстрактной. Под ней я как раз имел ввиду некоторые заимствования из динамических языков.
Если я все нашел правильно,
1. Первый динамический язык LISP появился в 1958 году.
2. Первый статический язык с выведением типов Meta Language появился в 1973
Но вот чем именно вдохновлялись разработчики определенных языков, наверняка уже не узнать, к сожалению, или к счастью)
У меня нет сомнений, что это нормальная фича.
Статья про то, что ее нужно использовать осознанно, как и любой другой инструмент.
Предложение звучит полностью так.
Сам по себе var не плохой. Плохая идея использовать его бездумно везде.
Как это аукнется:
Меньше контроля за контрактами. За счет того что типы скрыты, на возникает меньше поводов задуматься о правильности контрактов и композиции.
В своей практике часто замечал проблемы в коде, именно когда на глаза попадался сомнительный тип переменной в контексте метода.
+ Общее замедление ревью
В статье нигде и не написано, что java стала динамическим языком от этого.
Но фишка с выведением типов появилась, потому что опыт динамических языков показал, что так писать может быть удобно в некоторых случаях. По этому подобный сахар принесли во многие статические языки.
Так я и не говорю, что неявные типы это плохо.
Я говорю о том, что нужно позаботиться о том, чтобы код было удобно читать.
Иногда удобно записать все в одну строку и опустить типы,
иногда необходимо явно подсветить какой тип у нас есть на определенном этапе.
С появлением var перед разработчиком вариативности как писать стало больше.
Мое мнение, что писать везде var вместо полноценного типа только потому, что так позволяет компилятор и это короче - не верно.
"в статически типизированные языки пытаются привнести динамики",
фраза написана так.
я не говорю что java становится от наличия var динамически типизированным языком.
Но этот синтаксический сахар в работу с java привносит одну особенность из динамических языков. Если я объявил переменную, я могу менять ее значение при рефакторинге на любой тип, не меня объявление переменной.
Либо просто не задумываться о типе переменной при ее создании.
В java так изначально не было. Подсмотрели это в динамических языках.
Спасибо,
исправил
Не, ни в коем случае я этого не пытаюсь сделать,
задача NotificztionService соединить запрос с ответом и отдать событие о том, что ответ получен сервисуу который генерировал запрос. В нашем случае AuthService, а уже его задача принять решение о разлогине.
Согласен что в примере не однозначно отразил идею, подумаю как скорректировать. Хотя я явно прописал, что в NotificationService нельзя явно вызывать логику разлогина
Да, физически это 2 отдельных потока, но в этом и смысл дизайна, чтобы не обременять AuthService особенностями физики, а дать понятную абстракцию "запрос-ответ-реакция".
Вы же если в магазине заказываете товар которого нет в наличии приходите забирать его в этот же магазин, а не едете на склад.
Да, поездка на склад вполне рабочий вариант, но будет не очень удобно
Принципиально новая логика, потому что это интеграционное взаимодействие, в рамках которого нужно тянуть данные с почтового ящика. Это полноценная отдельная сложная работа, которую нельзя просто так вмазать в то что уже есть, нужно изолировать.
Привычно и логично, потому что по своей сути это вызов функции с возвращаемым значением, и хотелось бы чтобы это так и выглядело (как вызов метода, для этого и был дан "рецепт 2"), независимо от того как оно устроено внутри. Не должно быть распадания на 2 независимых потока (исходящий и входящий).
NotificationResponseListener не имеет полномочий принимать решение о том что нужно разлогинить, это ответственность AuthService.
NotificationResponseListener только обеспечивает входной трафик, не вдаваясь в суть входящих сообщений.
Потому что репозиторий как правило предполагает долговременное хранение с целью обмена, а кэш это как раз временное хранилище для оптимизации взаимодействия с целевым хранилищем
По поводу репозитория вы правы, но пример был про то, что явно прописанная аннотация Transactional в примере не окажет влияния на границы транзакции.
Пример и разбор скорректировал, чтобы снизить вероятность разночтения.
Спасибо за замечание)
Вся статья пропитана субъективным восприятием по типу
"я из за не умения пользоваться молотком размаждил себе палец, по этому молотки это зло созданное чтобы ломать пальцы"
В самом скрам нет проблем, это узкоспециализировнный инструмент, подходящих для конкретных задач, а для каких то неподходящий.
Проблема в людях, которые относятся к нему как к унивирсальной пилюле, сующтх скрам туда где он не нужен.
Потом его" адаптируют" и получается нечто что можно охарактеризовать как "работа по спринтам"
А дальше пишут статьи что скрам плохой...