Вам повезло не писать код для сервисов с миллиардами запросов в сутки. Количество параметров в конструкторе вас беспокоит? Ну а если вы тянете 20 полей из таблицы БД, какая вам разница? Билдер вам хоть чем то поможет? Не смешите. Зря потраченное время.
1) сборка мусора. Параметры функции передаются через стек, поля объекта создаются в куче. Начните только профайлинг. Много интересного узнаете.
2) Ад бесконтрольного роста количества классов с единственной целью, удовлетворить какую то одну функцию. От функции то вы ведь все равно не избавитесь. Так как она работу делает. А лишний класс - это зло.
3) По хорошему, а нахрена теперь Ломбок, если есть рекорды? У меня мало в каких проектах применяется. Ей Богу, когда меня начинают убеждать, что сроки сорваны из за набора сеттеров и геттеров, которые все равнo IDE сгенерировала, то не знаешь, то ли смеяться, то ли по ушам настучать.
У меня проектов десятки. Где то используется спринг, где то нет. Где то есть Ломбок, где то нет. Давать пример продакшн кода невозможно по многим причинам. 1) Нельзя. 2) Он слишком большой для статьи. 3) Придется писать еще две стать с обоснованием, почему принятое решение оптимально. А иначе набегут спецы давать советы. Что собственно и происходит.
Как будто кто то с ними спорит, что есть много способов ободрать кролика.
Если же посмотреть на проблему сверху, то окажется, что наибольшую пользу функции начинают приносить в Дата Ориентированном подходе к разработке. В этом случае ОО превращается в узкое место. Уже не помогает, а мешает. Просто начинает тонуть в обилии классов делающих почти но не совсем то же самое. Уж не говоря про эффективность.
Перейти же целиком на функциональные рельсы мешают внешние обстоятельства и решения.
Не вполне понимаю ваш вопрос. Этот данный проект полностью независим от каких либо иных библиотек и написан на ванильной Java. А дальше, можно использовать как угодно.
И да, любой конструктор с N параметрами эквивалентен FunctionN
А чем, мне правда интересно, читабельность хуже? Она просто такая какая есть. Нут ничего изменить нельзя. Если и функции 10 параметров, то в Java вынь да положь перечислить их все. включая подтипы.
И что непонятного в, например, applyArg1(value)?
Функция вернула функцию. Обычный прием. Только на кор джава в разы больше набирать. Вот уж где точно с читабельностью полный затык будет.
Если у человека достаточный опыт чтения джавовского функционального кода, то лично я не вижу никакой разницы.
К теме как раз не относится ни Скала, ни Котлин, ни F#. Потому что есть корпоративная реальность. Вы приходите на проект и вам сообщают, что писать надо на Java. Ваше блеяние о том, что Котлин лучше никого из менеджмента не интересует. Соответственно, цель всего этого - выжать максимум из того что доступно в данном конкретном инструменте.
А я нет. Для легковесной функциональщины достаточно того что есть в Java, плюс минус некоторые расшитрения, типа обсуждаемый. Для тяжелой артиллерии есть Кложур. Скала рядом не валялась.
Ну а вы, видимо, считаете, что раскрыли мне глаза.
Ну модифицируйте теперь этот код для двух индексов, трех, четырех.
Я порадуюсь за вас, как вы все это будете вытягивать через один параметр.
Мои расширения, конечно, не дают почти никаких преимуществ на числе параметров 1 и 2, которые уже реализованы стандартно, а у меня нужны исключительно для связности.
Ну атомик бутылочным горлышком редко становится. Поскольку синхронизацию не использует. Тут важна сама идея захвата объекта в контексте функции, а не вне ее.
Уменьшить страдание я и хотел. Тема о том, "а вот в Хаскеле это намного круче" конечно интересная, но я собственно адресую к тем, кому не шашечки, а ехать. Java так Java.
Скала пытается усидеть сразу на всем. И в этом ее беда. Кложур же является диалектом Лиспа, и карриривание просто естественная часть его жизненного цикла разработки. У него другая проблема, как и у любого Лиспа. Недостаток выразительных средств. Все терема высекаются одним топором.
Вообще "зачем все это нужно" вопрос правильный, но заслуживающий не стали даже, а книги целой. И, сдается мне, они уже написаны. В двух словах, последовательное применение FP сильно облегчает написание Data Oriented программ. То есть, таких программ, где из за сложности данных, с которыми приходится работать, сама по себе парадигма ООП становится антипатерном.
Моя цель была именно остаться в пределах ванильной Java. Конечно, любой может объявить какой угодно функциональный интерфейс. Для этого библиотеки не нужны. Но реальная польза от него возникает только если одновременно создается вся цепочка интерфейсов, связанных друг с другом. А это лишняя работа, которая делать не хочется.
И тут полезно иметь какой то шаблон, а не переизобретать велосипед каждый раз.
То что в Котлин ФП реализовано получше я не спорю. Было бы и странно, если не так. Но, в защиту Java, ФП в нее было добавлено поверх грандиозной легаси. Добавлено с полным сохранением обратной совместимости кода. А это подвиг почти.
Вспомните, любители Скалы, танцы с бубнами вокруг перехода на версию 2.1
Да простит меня автор, но Скала - просто жуткий язык. Один из неудачных примеров языков созданных из академического любопытства, а не по необходимости. Такого безумного количества конструкций ради попыток впихнуть все известные парадигмы программирования я в других современных языках не знаю.Не удивительно, что после появления Котлина и фейслифтинга Java, от Скала стали по возможности отказываться. В конце концов, если вам нужен ФП в какой-то части проекта можно задействовать Кложур. Уж с ним-то точно все ясно.
Давно сам лично не работал с Spring Expression. Обновил знания.
Главная моя претензия к SE — этот язык не очень здорово подходит для динамического исполнения. Собственно, и создавался то для параметризации статичных XML файлов. У меня можно по выбору, либо включать литерал непосредственно шаблон пути — а это удобно если все просто, никогда не меняется и описывается короткими строками, либо можно передать все параметры в массиве и ссылаться на них как $1, $2, и т.д. Не надо мудрить с генерацией путей, как это пришлось бы делать с SE. Обратные ссылки, опять же. Не только this или root, а любой однажды возникший в контексте объект в порядке их появления.
Чего у меня нет — вкусностей при работе со списками, и не уверен, надо ли. Попробуйте меня переубедить.
Так же у меня нет именованных параметров. Думал об этом, но не сложилась пока общая картина. Скажем, вместо $2 написать $userEmail, как то так.
Да собственно, можно вообще любой скриптовый язык задействовать. Хоть JavaScript, или Python. В данном случае, отказ от усложнения вполне сознательный. Ну и, не используется SPRING. Я, лично, даже не в курсе, можно ли каким-то естественным образом извлечь и использовать только один язык из всей монстроидной корневой библиотеки SPRING
1) Если поле необходимо переименовать, то есть возможность сохранить старое имя используя аннотацию @PathElement.
2) Насчет тормозов — все зависит от обстоятельств.
Вам повезло не писать код для сервисов с миллиардами запросов в сутки. Количество параметров в конструкторе вас беспокоит? Ну а если вы тянете 20 полей из таблицы БД, какая вам разница? Билдер вам хоть чем то поможет? Не смешите. Зря потраченное время.
Два момента:
1) сборка мусора. Параметры функции передаются через стек, поля объекта создаются в куче. Начните только профайлинг. Много интересного узнаете.
2) Ад бесконтрольного роста количества классов с единственной целью, удовлетворить какую то одну функцию. От функции то вы ведь все равно не избавитесь. Так как она работу делает. А лишний класс - это зло.
3) По хорошему, а нахрена теперь Ломбок, если есть рекорды? У меня мало в каких проектах применяется. Ей Богу, когда меня начинают убеждать, что сроки сорваны из за набора сеттеров и геттеров, которые все равнo IDE сгенерировала, то не знаешь, то ли смеяться, то ли по ушам настучать.
У меня проектов десятки. Где то используется спринг, где то нет. Где то есть Ломбок, где то нет. Давать пример продакшн кода невозможно по многим причинам. 1) Нельзя. 2) Он слишком большой для статьи. 3) Придется писать еще две стать с обоснованием, почему принятое решение оптимально. А иначе набегут спецы давать советы. Что собственно и происходит.
Как будто кто то с ними спорит, что есть много способов ободрать кролика.
Если же посмотреть на проблему сверху, то окажется, что наибольшую пользу функции начинают приносить в Дата Ориентированном подходе к разработке. В этом случае ОО превращается в узкое место. Уже не помогает, а мешает. Просто начинает тонуть в обилии классов делающих почти но не совсем то же самое. Уж не говоря про эффективность.
Перейти же целиком на функциональные рельсы мешают внешние обстоятельства и решения.
Не вполне понимаю ваш вопрос. Этот данный проект полностью независим от каких либо иных библиотек и написан на ванильной Java. А дальше, можно использовать как угодно.
И да, любой конструктор с N параметрами эквивалентен FunctionN
А чем, мне правда интересно, читабельность хуже? Она просто такая какая есть. Нут ничего изменить нельзя. Если и функции 10 параметров, то в Java вынь да положь перечислить их все. включая подтипы.
И что непонятного в, например, applyArg1(value)?
Функция вернула функцию. Обычный прием. Только на кор джава в разы больше набирать. Вот уж где точно с читабельностью полный затык будет.
Если у человека достаточный опыт чтения джавовского функционального кода, то лично я не вижу никакой разницы.
К теме как раз не относится ни Скала, ни Котлин, ни F#. Потому что есть корпоративная реальность. Вы приходите на проект и вам сообщают, что писать надо на Java. Ваше блеяние о том, что Котлин лучше никого из менеджмента не интересует. Соответственно, цель всего этого - выжать максимум из того что доступно в данном конкретном инструменте.
А я нет. Для легковесной функциональщины достаточно того что есть в Java, плюс минус некоторые расшитрения, типа обсуждаемый. Для тяжелой артиллерии есть Кложур. Скала рядом не валялась.
Ну а вы, видимо, считаете, что раскрыли мне глаза.
Ну модифицируйте теперь этот код для двух индексов, трех, четырех.
Я порадуюсь за вас, как вы все это будете вытягивать через один параметр.
Мои расширения, конечно, не дают почти никаких преимуществ на числе параметров 1 и 2, которые уже реализованы стандартно, а у меня нужны исключительно для связности.
Ну атомик бутылочным горлышком редко становится. Поскольку синхронизацию не использует. Тут важна сама идея захвата объекта в контексте функции, а не вне ее.
О! Спасибо что напомнили о стримах.
Сколько раз вы сталкивались с необходимостью получить индекс объекта в стриме?
Вот как это можно сделать с помощью карринга и SupplierExt
Заметьте, AtomicInteger нигде вне контекста не доступен, и никто не сможет как то исказить данные.
Уменьшить страдание я и хотел. Тема о том, "а вот в Хаскеле это намного круче" конечно интересная, но я собственно адресую к тем, кому не шашечки, а ехать. Java так Java.
Скала пытается усидеть сразу на всем. И в этом ее беда. Кложур же является диалектом Лиспа, и карриривание просто естественная часть его жизненного цикла разработки. У него другая проблема, как и у любого Лиспа. Недостаток выразительных средств. Все терема высекаются одним топором.
Вообще "зачем все это нужно" вопрос правильный, но заслуживающий не стали даже, а книги целой. И, сдается мне, они уже написаны. В двух словах, последовательное применение FP сильно облегчает написание Data Oriented программ. То есть, таких программ, где из за сложности данных, с которыми приходится работать, сама по себе парадигма ООП становится антипатерном.
Моя цель была именно остаться в пределах ванильной Java. Конечно, любой может объявить какой угодно функциональный интерфейс. Для этого библиотеки не нужны. Но реальная польза от него возникает только если одновременно создается вся цепочка интерфейсов, связанных друг с другом. А это лишняя работа, которая делать не хочется.
И тут полезно иметь какой то шаблон, а не переизобретать велосипед каждый раз.
То что в Котлин ФП реализовано получше я не спорю. Было бы и странно, если не так. Но, в защиту Java, ФП в нее было добавлено поверх грандиозной легаси. Добавлено с полным сохранением обратной совместимости кода. А это подвиг почти.
Вспомните, любители Скалы, танцы с бубнами вокруг перехода на версию 2.1
С каррированием лучше в Кложур, если уж на то. ;)
Да простит меня автор, но Скала - просто жуткий язык. Один из неудачных примеров языков созданных из академического любопытства, а не по необходимости. Такого безумного количества конструкций ради попыток впихнуть все известные парадигмы программирования я в других современных языках не знаю.Не удивительно, что после появления Котлина и фейслифтинга Java, от Скала стали по возможности отказываться. В конце концов, если вам нужен ФП в какой-то части проекта можно задействовать Кложур. Уж с ним-то точно все ясно.
Reference JDK implementation suggests the following code:
Главная моя претензия к SE — этот язык не очень здорово подходит для динамического исполнения. Собственно, и создавался то для параметризации статичных XML файлов. У меня можно по выбору, либо включать литерал непосредственно шаблон пути — а это удобно если все просто, никогда не меняется и описывается короткими строками, либо можно передать все параметры в массиве и ссылаться на них как $1, $2, и т.д. Не надо мудрить с генерацией путей, как это пришлось бы делать с SE. Обратные ссылки, опять же. Не только this или root, а любой однажды возникший в контексте объект в порядке их появления.
Чего у меня нет — вкусностей при работе со списками, и не уверен, надо ли. Попробуйте меня переубедить.
Так же у меня нет именованных параметров. Думал об этом, но не сложилась пока общая картина. Скажем, вместо $2 написать $userEmail, как то так.
2) Насчет тормозов — все зависит от обстоятельств.