Spring Data JDBC умеет маппить результаты SQL-запросов прямо в DTO
И вот дискуссия из ORM не нужны плавно перетекает в плоскость - я не люблю Хибернейт. А люблю Spring Data JDBC. То есть Hibernate, который правильно приготовлен ))
Уже много лет использую только jdbcTemplate и его производные
А какие производные имеются в виду? Интересно, что получается всё-таки, какая-то ещё абстракция вам нужна и вы почему-то не считаете её лишней. Любопытно чего вам хватает
Важный момент ещё. В РФ British Council включен в список нежелательных организаций, за финансирование которых могут последовать санкции. Поэтому возможно имеет смысл сдавать экзамен в какой-то другой организации
Очень приятно, когда автор появляется в комментариях!
Сильно рябит в глазах от выделений?
Нет, но из-за них не понятно кто писал текст - человек или ИИ ((. Раньше не было такой проблемы. То, что сгенерировал ИИ я буду читать только по необходимости, то что писал человек совсем другое дело ))
В статье большое количество пунктов и выделений жирным. Обычно так пишет ИИ. Ещё немного и для хоть какой-то уверенности, что писал живой человек, надо будет просить приложить видео, как он пишет и правит текст.
Сейчас я делаю вывод исходя из того, отметился ли автор в комментариях. Если нет, то точно писал ИИ
Что мешает Java развиваться перенимая фичи из ФП но не становясь чистым ФП языком?
Ничего не мешает, так и происходит. Но switch по типам это чуть ли не из чистого Си подход и использоваться в джаве он будет примерно так же.
Джава сообщество, особенно того старого формата приняло такое за одну ночь?
Да, моментально. Циклы поменялись в исходниках на стримы практически сразу. Многие вообще стали писать
Optional.ofNullable(something).ifPresent(something-> something.doSomething()) вместо
if (something != null) something.doSomething()
var, например, даже близко не получил такого распространения. Больше стримов, наверное, завирусился только Lombok, хотя по его поводу и правда встречается негатив.
Не смешите мои тапочки, там у людей спустя годы истерика не проходила.
Есть в интернете хотя бы одна статья по этому поводу? Хотя бы одна цитата? Только Бугаенко по этому поводу высказывался и его за это же и хейтят всем миром
Так вы определитесь возвращает он ответ или принимает аргумент (callback с единым интерфейсом).
Ну да, я тут коряво написал. У возвращаемого объекта должен быть метод типа orElse у Optional, который примет коллбэки. И результат будет примерно такой же как у ПМ.
Думаю, что вы отлично всё поняли, но решили дурочка включить.
Ну нет, я хотел сказать, что одну и ту же задачу можно решить и паттерн матчингом и полиморфизмом. И хочется увидеть пример, который явно решается только паттерн-матчингом. Про то, что решается только полиморфизмом, вы очень доходчиво и хорошо написали.
Возможно пример с Either тоже такой же хороший, я просто не понимаю. Но пока мне кажется, что можно тут заменить паттерн матчинг на колбеки, то есть полиморфизм.
Если это выглядит как ФП, пишеться как ФП и работает как ФП, то это, ... разумеется старый добрый процедурный подход.
В статье Гётц пишет, что ФП это когда всё это функция. Наверное он так и думает. И если бы он считал, что главное в истории с рекордами и паттерн матчингом это добавление в Джаву элементов ФП он бы так и сказал.
Подхода "всё это функция" в Джаве нет и не планируется, понятия чистых функций нет и не планируется, за сайд эффектами никто не следит и не собирается.
А все потому что дальновидный Brian Goetz написал "Data Oriented Programming" видимо мудро предвосхищая что напиши он ФП то у фанатов ООП случиться истерика.
Когда в Джаве появились лямбды и стримы, то радостные крики джава-программистов были слышны на весь Интернет. Циклы заменили стримами моментально, практически за ночь. Все открыто говорили и до сих пор говорят, что вот оно наше ФП в джаве, дайте ещё да побольше.
И фанатов ООП, которые хоть как-то бы это осудили было человека три. А таких, кто хотел вообще убрать ООП и оставить только ФП, таких много было. Специально для них даже писали статьи, что ФП и ООП вообще никак не мешают друг другу и живут мирно. Так что нет, джава-программисты любят элементы ФП всем сердцем. Кроме, может быть, имутабельности.
Ну вот пример с Shape, Circle и Rectangle, который обсуждали чуть выше. Добавить Polygon ещё какой-нибудь, чтобы он выглядел более-менее реалистичным. Данные разные, но подсчёт площади приводят как хрестоматийный пример применения полиморфизма
Either на полиморфизме не сделаешь.
Ну как. Допустим метод возвращает объект, который может быть ошибкой или нормальным значением. И надо выполнить один код, если это ошибка и другой, если это значение. Этот метод может принимать дополнительный аргумент, в котором будет объект, реализующий интерфейс с двумя методами. Один метод для действия, которое надо произвести, если случилась ошибка и другой для действия, которое надо сделать с нормальным результатом. Мне кажется вот так можно. Или я неправильно всё понял?
Дизайнеры новых языков программирования. Чем младше язык, тем меньше вероятность, что там будет goto. А если и будет, то совсем не тот, я в языках из прошлого века
В Java он есть, но я не видел чтобы его кто-то использовал.
Он есть, но от того, как его использовали в C осталась только одна маленькая часть - прыжки по циклам. А другого ничего нет. Потому что если бы было, люди бы писали код, который Дийкстра в своё время предложил считать вредным
Shape, Circle и Rectangle с подсчётом площади? Это ж как раз идеальный кейс для ПМ и sealed интерфейсов. Если у нас есть закрытый интерфейс Shape, у которого две реализации Circle и Rectangle, то для подсчёта площади можно сделать один метод, в котором switch с pattern matching и в ветках возвращается площадь, посчитанная по соответствующей формуле.
Это не только производительнее, но ещё и даёт программисту возможность понять, что формулы для посчёта площади круга и прямоугольника по большому счёту не отличаются ничем, кроме коеффициента, который можно хранить в таблице, рядом с этим же методом
Ну только Data Oriented Programming с функциональным программированием имеет примерно столько же общего, сколько с ООП. Рекорды имутабельные, имутабельность, конечно, ключевой компонент ФП, но не ключевой компонент Data Oriented Programming.
То о чём пишет Гётц это традиционный старый добрый процедурный подход. Данные отдельно, код, который их обрабатывает отдельно. Который да, де факто в серверных приложениях сейчас повсюду.
Паттерн матчинг в свитчах провоцирует писать код, который не использует полиморфизм, то есть провоцирует к отходу от парадигмы ООП, вот что я хотел сказать.
Возможно, надо раскрыть, почему я называю ПМ и ООП ортогональными понятиями?
Мне была бы любопытна ваша точка зрения по вопросу, где точно надо использовать ПМ, а где точно надо использовать полиморфизм. Без краевых случаев, а вот где явно то, а где явно другое.
И вот дискуссия из ORM не нужны плавно перетекает в плоскость - я не люблю Хибернейт. А люблю Spring Data JDBC. То есть Hibernate, который правильно приготовлен ))
А какие производные имеются в виду? Интересно, что получается всё-таки, какая-то ещё абстракция вам нужна и вы почему-то не считаете её лишней. Любопытно чего вам хватает
Абстракция, нюансы работы которой нужно знать, да. Но что она лишняя это ещё надо доказать.
Знание SQL это общее место. Неожиданно, что ещё надо знать, как работает jdbc.
Разрабатывать с помощью голого jdbc без Hibernate? Я подозреваю, что вы уже очень давно этого не делали. Экспириенс ухудшится и ещё как
Тем, что в не-самодельных решениях накапливаются оптимальные решения для всех типичных кейсов
Собственно да. Не боги, но люди, которые годами занимаются именно этими решениями.
Важный момент ещё. В РФ British Council включен в список нежелательных организаций, за финансирование которых могут последовать санкции. Поэтому возможно имеет смысл сдавать экзамен в какой-то другой организации
Да и в комментариях он появился
Очень приятно, когда автор появляется в комментариях!
Нет, но из-за них не понятно кто писал текст - человек или ИИ ((. Раньше не было такой проблемы. То, что сгенерировал ИИ я буду читать только по необходимости, то что писал человек совсем другое дело ))
В статье большое количество пунктов и выделений жирным. Обычно так пишет ИИ. Ещё немного и для хоть какой-то уверенности, что писал живой человек, надо будет просить приложить видео, как он пишет и правит текст.
Сейчас я делаю вывод исходя из того, отметился ли автор в комментариях. Если нет, то точно писал ИИ
Эллипс и треугольник точно так же считаются. Коеффициент умножить на один параметр, умножить на другой.
Площать треугольника - 0.5 * основание * высота
Площадь эллипса - pi * большая полуось * малася полуось
Практически одна и та же формула ))
Ничего не мешает, так и происходит. Но switch по типам это чуть ли не из чистого Си подход и использоваться в джаве он будет примерно так же.
Да, моментально. Циклы поменялись в исходниках на стримы практически сразу. Многие вообще стали писать
Optional.ofNullable(something).ifPresent(something-> something.doSomething()) вместо
if (something != null) something.doSomething()
var, например, даже близко не получил такого распространения. Больше стримов, наверное, завирусился только Lombok, хотя по его поводу и правда встречается негатив.
Есть в интернете хотя бы одна статья по этому поводу? Хотя бы одна цитата? Только Бугаенко по этому поводу высказывался и его за это же и хейтят всем миром
Ну да, я тут коряво написал. У возвращаемого объекта должен быть метод типа orElse у Optional, который примет коллбэки. И результат будет примерно такой же как у ПМ.
Ну нет, я хотел сказать, что одну и ту же задачу можно решить и паттерн матчингом и полиморфизмом. И хочется увидеть пример, который явно решается только паттерн-матчингом. Про то, что решается только полиморфизмом, вы очень доходчиво и хорошо написали.
Возможно пример с Either тоже такой же хороший, я просто не понимаю. Но пока мне кажется, что можно тут заменить паттерн матчинг на колбеки, то есть полиморфизм.
В статье Гётц пишет, что ФП это когда всё это функция. Наверное он так и думает. И если бы он считал, что главное в истории с рекордами и паттерн матчингом это добавление в Джаву элементов ФП он бы так и сказал.
Подхода "всё это функция" в Джаве нет и не планируется, понятия чистых функций нет и не планируется, за сайд эффектами никто не следит и не собирается.
Когда в Джаве появились лямбды и стримы, то радостные крики джава-программистов были слышны на весь Интернет. Циклы заменили стримами моментально, практически за ночь. Все открыто говорили и до сих пор говорят, что вот оно наше ФП в джаве, дайте ещё да побольше.
И фанатов ООП, которые хоть как-то бы это осудили было человека три. А таких, кто хотел вообще убрать ООП и оставить только ФП, таких много было. Специально для них даже писали статьи, что ФП и ООП вообще никак не мешают друг другу и живут мирно. Так что нет, джава-программисты любят элементы ФП всем сердцем. Кроме, может быть, имутабельности.
Это наше будущее ))
Ну вот пример с Shape, Circle и Rectangle, который обсуждали чуть выше. Добавить Polygon ещё какой-нибудь, чтобы он выглядел более-менее реалистичным. Данные разные, но подсчёт площади приводят как хрестоматийный пример применения полиморфизма
Ну как. Допустим метод возвращает объект, который может быть ошибкой или нормальным значением. И надо выполнить один код, если это ошибка и другой, если это значение. Этот метод может принимать дополнительный аргумент, в котором будет объект, реализующий интерфейс с двумя методами. Один метод для действия, которое надо произвести, если случилась ошибка и другой для действия, которое надо сделать с нормальным результатом. Мне кажется вот так можно. Или я неправильно всё понял?
Дизайнеры новых языков программирования. Чем младше язык, тем меньше вероятность, что там будет goto. А если и будет, то совсем не тот, я в языках из прошлого века
Он есть, но от того, как его использовали в C осталась только одна маленькая часть - прыжки по циклам. А другого ничего нет. Потому что если бы было, люди бы писали код, который Дийкстра в своё время предложил считать вредным
Shape, Circle и Rectangle с подсчётом площади? Это ж как раз идеальный кейс для ПМ и sealed интерфейсов. Если у нас есть закрытый интерфейс Shape, у которого две реализации Circle и Rectangle, то для подсчёта площади можно сделать один метод, в котором switch с pattern matching и в ветках возвращается площадь, посчитанная по соответствующей формуле.
Это не только производительнее, но ещё и даёт программисту возможность понять, что формулы для посчёта площади круга и прямоугольника по большому счёту не отличаются ничем, кроме коеффициента, который можно хранить в таблице, рядом с этим же методом
А эталонный пример для полиморфизма?
Ну только Data Oriented Programming с функциональным программированием имеет примерно столько же общего, сколько с ООП. Рекорды имутабельные, имутабельность, конечно, ключевой компонент ФП, но не ключевой компонент Data Oriented Programming.
То о чём пишет Гётц это традиционный старый добрый процедурный подход. Данные отдельно, код, который их обрабатывает отдельно. Который да, де факто в серверных приложениях сейчас повсюду.
Собственно поэтому его и убрали
Паттерн матчинг в свитчах провоцирует писать код, который не использует полиморфизм, то есть провоцирует к отходу от парадигмы ООП, вот что я хотел сказать.
Мне была бы любопытна ваша точка зрения по вопросу, где точно надо использовать ПМ, а где точно надо использовать полиморфизм. Без краевых случаев, а вот где явно то, а где явно другое.