Навіщо використовувати необов’язково в Java 8+ замість традиційних перевірок нульових покажчиків?

Нещодавно ми перейшли на Java 8. Тепер я бачу додатки, залиті Optionalоб’єктами.

Перед Java 8 (Стиль 1)

Employee employee = employeeServive.getEmployee();

if(employee!=null){
    System.out.println(employee.getId());
}

Після Java 8 (Стиль 2)

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employee = employeeOptional.get();
    System.out.println(employee.getId());
}

Я не бачу додаткової вартості, Optional<Employee> employeeOptional = employeeService.getEmployee();коли сама служба повертається необов'язково:

Починаючи з фону Java 6, я вважаю Стиль 1 більш чітким і з меншою кількістю рядків коду. Чи є якась реальна перевага, якої мені тут не вистачає?

Консолідований з розуміння всіх відповідей та подальших досліджень у блозі

Стиль 2 не збирається Java 8 достатньо, щоб побачити всю перевагу. Ви зовсім не хочете if ... use. Дивіться приклади Oracle . Дотримуючись їх порад, ми отримуємо:

Стиль 3

// Changed EmployeeServive to return an optional, no more nulls!
Optional<Employee> employee = employeeServive.getEmployee();
employee.ifPresent(e -> System.out.println(e.getId()));

Або більш тривалий фрагмент

Optional<Employee> employee = employeeServive.getEmployee();
// Sometimes an Employee has forgotten to write an up-to-date timesheet
Optional<Timesheet> timesheet = employee.flatMap(Employee::askForCurrentTimesheet); 
// We don't want to do the heavyweight action of creating a new estimate if it will just be discarded
client.bill(timesheet.orElseGet(EstimatedTimesheet::new));

Якщо ви використовуєте Optionalшар "сумісності" між старішим API, який все ще може повернутися null, можливо, буде корисним створити (не порожній) необов'язковий на останньому етапі, щоб ви впевнені, що у вас щось є. Наприклад, де ви писали:

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

Я б вирішив:

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

Справа в тому , що ви знаєте , що є непорожній співробітник служби , так що ви можете обернути , що в Optionalс Optional.of(). Тоді, коли ви зателефонуєте getEmployee()з цього приводу, ви можете або не можете отримати працівника. Цей працівник може (або, можливо, може не мати) посвідчення особи. Потім, якщо у вас з’явився ідентифікатор, ви хочете роздрукувати його.

Там немає необхідності явно перевірити будь-який нуль, наявність і т.д., в цьому коді.

Існує поруч із доданою вартістю наявність Optionalодного значення. Як ви бачили, це просто замінює чек на nullчек на наявність.

Існує величезна додаткова вартість у наявності Collectionтаких речей. Усі потокові методи, запроваджені на заміну циклів низького рівня старого стилю, розуміють Optionalречі та роблять правильно їх (не обробляючи їх або в кінцевому рахунку повертаючи інше невдале Optional). Якщо ви маєте справу з n предметами частіше, ніж з окремими предметами (а це реалізує 99% усіх реалістичних програм), то це величезне вдосконалення, щоб мати вбудовану підтримку необов'язково представлених речей. В ідеальному випадку вам ніколи не доведеться перевіряти наявність null чи наявність.

Поки ви використовуєте так Optionalсамо, як фантазійний API для isNotNull(), тоді так, ви не знайдете жодних відмінностей, просто перевіривши null.

Речі, які НЕ слід використовувати Optionalдля

Використовуючи Optionalпросто для перевірки наявності значення Bad Code ™:

// BAD CODE ™ --  just check getEmployee() != null  
Optional<Employee> employeeOptional =  Optional.ofNullable(employeeService.getEmployee());  
if(employeeOptional.isPresent()) {  
    Employee employee = employeeOptional.get();  
    System.out.println(employee.getId());
}  

Речі , які ви повинні використовувати Optionalдля

Уникайте, щоб значення не було, створивши його, коли це необхідно, використовуючи методи, що повертають нуль:

Employee employee = Optional.ofNullable(employeeService.getEmployee())
                            .orElseGet(Employee::new);
System.out.println(employee.getId());

Або якщо створення нового працівника занадто дороге:

Optional<Employee> employee = Optional.ofNullable(employeeService.getEmployee());
System.out.println(employee.map(Employee::getId).orElse("No employee found"));

Також, усвідомлюючи всіх, що ваші методи можуть не повернути значення (якщо з будь-якої причини ви не можете повернути значення за замовчуванням, як вище):

// Your code without Optional
public Employee getEmployee() {
    return someCondition ? null : someEmployee;
}
// Someone else's code
Employee employee = getEmployee(); // compiler doesn't complain
// employee.get...() -> NPE awaiting to happen, devs criticizing your code

// Your code with Optional
public Optional<Employee> getEmployee() {
    return someCondition ? Optional.empty() : Optional.of(someEmployee);
}
// Someone else's code
Employee employee = getEmployee(); // compiler complains about incompatible types
// Now devs either declare Optional<Employee>, or just do employee = getEmployee().get(), but do so consciously -- not your fault.

І нарешті, є всі потокоподібні методи, які вже були пояснені в інших відповідях, хоча це насправді ви не вирішили використовувати, Optionalа скористаєтесь Optionalнаданими кимось іншим.

Ключовим моментом у використанні необов’язкового є чітке розуміння, коли розробнику потрібно перевірити, повертають чи функцію значення чи ні.

//service 1
Optional<Employee> employeeOptional = employeeService.getEmployee();
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

//service 2
Employee employee = employeeService.getEmployeeXTPO();
System.out.println(employee.getId());

Ваша основна помилка в тому, що ви все ще думаєте в більш процедурному плані. Це не мається на увазі як критика вас як особистості, це лише спостереження. Мислення в більш функціональному плані пов'язане з часом і практикою, а тому методи єПроявляйте і виглядайте як найбільш очевидні правильні речі, за якими потрібно закликати вас. Ваша вторинна незначна помилка - це створення Факультативного всередині вашого методу. Необов’язковий покликаний допомогти документувати, що щось може або не може повернути значення. Ви можете нічого не отримати.

Це призвело до того, що ви пишете ідеально розбірливий код, який здається цілком розумним, але вас спокусили мерзенні спокусниці-близнюки, які отримують і є присутній.

Звичайно, питання швидко стає "чому вони присутня і туди навіть?"

Що багато хто тут пропускає, це те, що isPresent () - це те, що це не те, що створено для нового коду, написаного людьми повністю на борту з тим, наскільки корисні лямбди, які люблять готівку, і яким подобається функціональна річ.

Однак це дає нам кілька (двох) добрих, чудових, гламурних (?) Переваг:

• Це полегшує перехід застарілого коду до використання нових функцій.
• Це полегшує криві навчання за вибором.

Перший досить простий.

Уявіть, у вас є API, який виглядав так:

public interface SnickersCounter {
  /** 
   * Provides a proper count of how many snickers have been consumed in total.
   */
  public SnickersCount howManySnickersHaveBeenEaten();

  /**
    * returns the last snickers eaten.<br>
    * If no snickers have been eaten null is returned for contrived reasons.
    */
  public Snickers lastConsumedSnickers();
}

І у вас був спадковий клас, використовуючи цей як такий (заповніть пробіли):

Snickers lastSnickers = snickersCounter.lastConsumedSnickers();
if(null == lastSnickers) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers);
}

Надуманий приклад, напевне. Але візьми зі мною тут.

Зараз запущена Java 8, і ми намагаємося вийти на борт. Отже, одна з речей, яку ми робимо, - це те, що ми хочемо замінити старий інтерфейс чимось, що повертає необов’язково. Чому? Тому що, як хтось уже милостиво згадував: Це виймає здогадки про те, чи може щось бути недійсним, на це вже вказували інші. Але зараз у нас є проблема. Уявіть, у нас є (вибачте, поки я натиснув alt + F7 невинним методом), 46 місць, де цей метод називається добре перевіреним спадковим кодом, який робить відмінну роботу інакше. Тепер ви повинні оновити все це.

ЦЕ це місце, де світить.

Тому що зараз: Snickers lastSnickers = snickersCounter.lastConsumedSnickers (); if (null == lastSnickers) {киньте новий NoSuchSnickersException (); } else {Consumer.giveDiabetes (lastSnickers); }

стає:

Optional<Snickers> lastSnickers = snickersCounter.lastConsumedSnickers();
if(!lastSnickers.isPresent()) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers.get());
}

І це проста зміна, яку ви можете дати новому молодшому: Він може зробити щось корисне, і він одночасно вивчить базу коду. безпрограшний. Зрештою, щось подібне до цієї моделі досить поширене. І тепер вам не доведеться переписувати код, щоб використовувати лямбда або що-небудь інше. (У цьому конкретному випадку це було б банально, але я залишаю придумувати приклади, коли це буде важко як вправу для читача.)

Зауважте, що це означає, що так, як ви це зробили, це по суті спосіб поводження зі застарілим кодом, не роблячи дорогих переписувань. То як бути з новим кодом?

Що ж, у вашому випадку, де ви просто хочете щось надрукувати, ви просто зробите:

snickersCounter.lastConsumedSnickers (). ifPresent (System.out :: println);

Що досить просто і абсолютно зрозуміло. Сенс, який повільно кидається на поверхню, полягає в тому, що існують випадки використання для get () та isPresent (). Вони там, що дозволяють механічно змінювати існуючий код, щоб використовувати новіші типи, не надто замислюючись про це. Отже, те, що ви робите, неправильно керується такими способами:

• Ви викликаєте метод, який може повернути нуль. Правильна думка полягала б у тому, що метод повертає null.
• Ви використовуєте застарілі методи бандайдів для боротьби з цим необов’язковим, замість того, щоб використовувати нові смачні методи, що містять лямбда-химерність.

Якщо ви хочете використовувати Необов’язково як просту перевірку безпеки на нуль, то, що ви повинні зробити, це просто:

new Optional.ofNullable(employeeServive.getEmployee())
    .map(Employee::getId)
    .ifPresent(System.out::println);

Звичайно, гарна версія цього виглядає так:

employeeService.getEmployee()
    .map(Employee::getId)
    .ifPresent(System.out::println);

До речі, хоча це аж ніяк не потрібно, я радимо використовувати новий рядок за операцією, щоб було легше читати. Легко читати і розуміти, щоби лаконічніше було в будь-який день тижня.

Це, звичайно, дуже простий приклад, коли легко зрозуміти все, що ми намагаємось зробити. У реальному житті це не завжди так просто. Але зауважте, як у цьому прикладі ми виражаємо свої наміри. Ми хочемо отримати працівника, отримати його посвідчення та, якщо можливо, роздрукувати його. Це другий великий виграш із Факультативом. Це дозволяє нам створити більш чіткий код. Я також думаю, що робити такі речі, як створення методу, який робить купу речей, щоб ви могли подати його на карту, взагалі хороша ідея.

Я не бачу вигоди в стилі 2. Вам все-таки потрібно усвідомити, що вам потрібна перевірка нуля, і тепер вона ще більша, таким чином, менш читабельна.

Кращим стилем було б, якби службовецьServive.getE Employee () повертає необов'язково, і тоді код стане:

Optional<Employee> employeeOptional = employeeServive.getEmployee();
if(employeeOptional.isPresent()){
    Employee employee= employeeOptional.get();
    System.out.println(employee.getId());
}

Таким чином, ви не можете calle EmployeeServive.getE Employee (). GetId (), і ви помічаєте, що вам слід якось обробити необов'язкове значення. І якщо у всій вашій кодовій базі методи ніколи не повертатимуть null (або майже ніколи з добре відомими вашій команді винятками з цього правила), це підвищить безпеку проти NPE.

Я думаю, що найбільша перевага полягає в тому, що якщо ваш підпис методу повертається, Employeeви не перевіряєте на null. Ви за цим підписом знаєте, що гарантовано повернути працівника. Вам не потрібно займатися справою несправності. З необов'язковим ви знаєте, що ви робите.

У коді, який я бачив, є нульові перевірки, які ніколи не вийдуть з ладу, оскільки люди не хочуть простежити за кодом, щоб визначити, чи можливий нуль, тому вони кидають нульові чеки скрізь оборонно. Це робить код трохи повільнішим, але що важливіше, він робить код набагато шумнішим.

Однак, щоб це працювало, вам потрібно застосовувати цю схему послідовно.

Моя відповідь: Просто не треба. Принаймні подумайте двічі, чи справді це поліпшення.

Вираз (узятий з іншої відповіді), як

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

представляється правильним функціональним способом поводження з спочатку незмінними методами повернення. Це виглядає приємно, він ніколи не кидає і ніколи не змушує задуматися про поводження з "відсутнім" справою.

Це виглядає краще, ніж старовинний спосіб

Employee employee = employeeService.getEmployee();
if (employee != null) {
    ID id = employee.getId();
    if (id != null) {
        System.out.println(id);
    }
}

що дає зрозуміти, що можуть бути elseпункти.

Функціональний стиль

• виглядає зовсім інакше (і не читається для людей, які його не використовували)
• - це біль для налагодження
• не може бути легко розширений для роботи з "відсутнім" випадком ( orElseне завжди достатньо)
• вводить в оману ігнорування "відсутньої" справи

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

Будучи великим шанувальником Java, я мушу сказати, що функціональний стиль - це лише бідна заміна Java заяві

employeeService
.getEmployee()
?.getId()
?.apply(id => System.out.println(id));

добре відомі з інших мов. Чи згодні ми з цим твердженням

• не є (справді) функціональним?
• дуже схожий на код старого стилю, просто набагато простіше?
• набагато легше читати, ніж функціональний стиль?
• є налагоджувачем?

Необов’язково - це концепція (тип вищого порядку), що походить від функціонального програмування. Використання його усуває вкладені нульові перевірки і рятує вас від піраміди приреченості.