Четыре сюрприза с Optional

Всем привет

После нашего тренинга «Стань экспертом с Java 8/9» 25-26 марта было много обсуждений, что и как использовать из Java 8, какие best/worst practices появились.

Поэтому я решил подитожить то, что касается работы с Optional и выделить в отдельную статью. К сожалению, ее нельзя получается опубликовать как статью здесь, поэтому я просто приложу ссылку для всех желающих: it-simulator.com/#/articlefull/274

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Сюрприз #5 — автор любит по пусту балаболить и пороть хню с умным видом - Хотя какой это сюрприз, он же ведет тренинг войтивайти

Это началось с «бизнес-тренеров». Они как правило тоже идеи с двух-трёх абзацев текста могут раскатать на час-полтора семинара.

А можете просто следует прочитать перед использованием вот этот линк docs.oracle.com/…​i/java/util/Optional.html ?

назва статті — типовий клікбайт, а під капотом як завжди шопопало.

сюрприз #2 — взагалі маразм, тут справа не в Optional, а в тому, що програміст не знає, що є така штука як empty або просто забув.

сюрприз #4 — притягнутий за вуха, приблизно так само, як і попередні, а все було зроблено ддя того, щоб розтягнути час для тренінгу, як я розумію.

Спасибо за ваш отзыв. Напишите пожалуйста ссылку на ваши статьи, чтобы мы у вас поучились, как это правильно делать

а для чого ще писати якусь статтю? коментом вище привели посилання на офіційну документацію по Optional. достатньо спочатку почитати, щоб використовувати без болю і наслідків

Если не готовы к отзывам, тогда лучше вообще не публиковаться. Это не фейсбучек, где все друзья друг другу ликают.

типичная манипуляция в стиле: а ты сначала добейся!

Я вот не умею готовить, значит ли это что я не имею права говорить что горячие суши это говнище?

чтобы мы у вас поучились, как это правильно делать
Поучитесь у него правильному — не делать. Он же не пишет никому не нужных статеек, вот и вы не пишите. А вообще агрументы в стиле «сперва добейся» выглядят довольно глупо.
Поучитесь у него правильному — не делать.
Лучший код — это ненаписанный код %)

Лучший айтишник — «невошедший» айтишник :)

Напишите пожалуйста ссылку на ваши статьи, чтобы мы у вас поучились, как это правильно делать

Раз такая песня: blog.idapgroup.com/…​als-without-conditionals.

Теперь по теме, пользуйте Kotlin и Funktionale (funKTionale) или любые другие либы-обертки или Scala и Scalaz. Optional в Java уныл, как сама Java. Либо уже хотя бы доносите мысль, что если опшнал используется, то должен использвоаться везде, т.е. делать его уровнем конвенции. Предлагаемая вами логика, что внутри либы не используем опшнал, а снаружи отдаем опшнал уныла и уничтожает немногочисленные достоинства, которым Optional в Java обладает.

А вот здесь:
System.out.println(optional.map(Product::getCustomer).map(Customer::getName).orElse("Not found"));

В случае, если у вас getCustomer и getName возвращают опшналы, то будет задница, т.к. вы получите, как результат Optional>>. flatMap надо использовать. Если же они у вас возвращают nullable values, то какой смысл в вашем апи? Защитили парсинг кода и забили на все остальные нуленебезопасные доступы по всему коду при работе с вашими продуктами и кастомерами.

З.Ы. Optional в Java в текущей имплементации слишком многословен и бесполезен. Закапывайте.

Optional в Java в текущей имплементации слишком многословен и бесполезен. Закапывайте.
fixed: optional в любом виде на практике бесполезен. Закапывайте.
fixed: golang в любом виде на практике бесполезен. Закапывайте.

Очевидный фикс вашей очепятки же.

К слову сказать, хз как в котлине и свифте, но в скале тоже вполне можно, в стиле автора статьи, спокойно себе стрелять по яйцам передавать\возвращать налл где должен быть опшнал. Что неопытный народ и прочие индусы часто и делают. У нас опытные товарищи на интегрейшене даже код стайл проверку затулили, если в коде есть слово налл — автоматом фейлить билд.

В котлине nullable — компилерный скрытый тип. С ним просто так не поработаешь небезопасно до null pointer exception, есть форсированный небезопасный доступ, но пользовать его не стоит: kotlinlang.org/…​eference/null-safety.html . Ну и джава код может покидать эксепшны.

В swift — это вообще полноценный тип, есть еще и небезопасные опшналы, но ими пользоваться не стоит от слова совсем.

В scala, если честно, впервые слышу, чтобы пользовали null. Т.е. знаю, что можно, но не знал, что есть те, кто используют.

Подписаться на комментарии