Por que usar Opcional no Java 8+ em vez das verificações tradicionais de ponteiro nulo?

Recentemente, mudamos para o Java 8. Agora, vejo aplicativos inundados de Optionalobjetos.

Antes do Java 8 (estilo 1)

Employee employee = employeeServive.getEmployee();

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

Após o Java 8 (estilo 2)

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

Não vejo valor agregado Optional<Employee> employeeOptional = employeeService.getEmployee();quando o serviço em si retorna opcional:

Vindo de um background Java 6, vejo o Estilo 1 como mais claro e com menos linhas de código. Existe alguma vantagem real que estou perdendo aqui?

Consolidado da compreensão de todas as respostas e de mais pesquisas no blog

O estilo 2 não usa o Java 8 o suficiente para ver todos os benefícios. Você não quer if ... usenada disso. Veja os exemplos da Oracle . Seguindo seus conselhos, obtemos:

Estilo 3

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

Ou um trecho mais longo

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));

Se você estiver usando Optionalcomo uma camada de "compatibilidade" entre uma API mais antiga que ainda pode retornar null, pode ser útil criar o opcional (não vazio) no estágio mais recente que você tem certeza de que possui alguma coisa. Por exemplo, onde você escreveu:

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

Eu optaria por:

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

O ponto é que você sabe que existe um serviço de funcionário não nulo , para que você possa encerrar isso Optionalcom um Optional.of(). Então, quando você ligar getEmployee()para isso, poderá ou não conseguir um funcionário. Esse funcionário pode (ou, possivelmente, pode não ter) um ID. Então, se você acabou com um ID, deseja imprimi-lo.

Não há necessidade de verificar explicitamente qualquer nulo, presença, etc., neste código.

Quase não há valor agregado em ter um Optionalvalor único. Como você viu, isso apenas substitui um cheque por nullum cheque pela presença.

Há um enorme valor agregado em ter uma Collectiondessas coisas. Todos os métodos de streaming introduzidos para substituir os loops de baixo nível no estilo antigo entendem as Optionalcoisas e fazem a coisa certa sobre elas (não processando-as ou retornando outra não configurada Optional). Se você lida com n itens com mais frequência do que com itens individuais (e 99% de todos os programas realistas o fazem), é uma grande melhoria ter suporte interno para itens opcionalmente presentes. No caso ideal, você nunca precisa verificar null ou presença.

Desde que você use Optionalexatamente como uma API sofisticada isNotNull(), sim, você não encontrará diferenças apenas com a verificação null.

Coisas que você não deve usar Optionalpara

Usar Optionalapenas para verificar a presença de um valor é 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());
}  

Coisas que você deve usar Optionalpara

Evite que um valor não esteja presente, produzindo um quando necessário ao usar métodos de API de retorno nulo:

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

Ou, se a criação de um novo funcionário for muito cara:

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

Além disso, informando a todos que seus métodos podem não retornar um valor (se, por qualquer motivo, você não puder retornar um valor padrão como acima):

// 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.

E, finalmente, existem todos os métodos de fluxo que já foram explicados em outras respostas, embora não seja realmente você que decida usar, Optionalmas faça uso do Optionalfornecido por outra pessoa.

O ponto chave para mim ao usar o Opcional é manter claro quando o desenvolvedor precisa verificar se a função retorna valor ou não.

//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());

Seu principal erro é que você ainda está pensando em termos processuais. Isso não é uma crítica a você como pessoa, é apenas uma observação. Pensar em termos mais funcionais vem com o tempo e a prática e, portanto, os métodos são apresentados e parecem as coisas corretas mais óbvias para você. Seu erro secundário secundário é criar o seu Opcional dentro do seu método. O Opcional tem como objetivo ajudar a documentar que algo pode ou não retornar um valor. Você pode não conseguir nada.

Isso fez com que você escrevesse um código perfeitamente legível que parecesse perfeitamente razoável, mas você foi seduzido pelas vil sedutoras sedutoras que são get e isPresent.

É claro que a pergunta rapidamente se torna "por que o isPresent está chegando lá?"

Uma coisa que muitas pessoas aqui sentem falta é isPresent (), que não é algo que é feito para um novo código escrito por pessoas totalmente a bordo com o quão bom é o lambda útil e quem gosta da coisa funcional.

No entanto, oferece alguns (dois) benefícios bons, ótimos e charmosos (?):

• Facilita a transição do código legado para usar os novos recursos.
• Facilita as curvas de aprendizado do Opcional.

O primeiro é bastante simples.

Imagine que você tenha uma API parecida com esta:

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();
}

E você tinha uma classe herdada usando isso como tal (preencha os espaços em branco):

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

Um exemplo inventado para ter certeza. Mas tenha paciência comigo aqui.

O Java 8 já foi lançado e estamos nos esforçando para entrar a bordo. Portanto, uma das coisas que fazemos é que queremos substituir nossa interface antiga por algo que retorne Opcional. Por quê? Porque, como alguém já mencionou graciosamente: Isso elimina a suposição de se algo pode ou não ser nulo. Isso já foi apontado por outros. Mas agora temos um problema. Imagine que temos (desculpe-me enquanto pressiono alt + F7 em um método inocente), 46 lugares em que esse método é chamado em código legado bem testado que, caso contrário, faz um excelente trabalho. Agora você precisa atualizar tudo isso.

É aqui que está presente o brilho.

Porque agora: Snickers lastSnickers = snickersCounter.lastConsumedSnickers (); if (null == lastSnickers) {lança novo NoSuchSnickersException (); } else {consumer.giveDiabetes (lastSnickers); }

torna-se:

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

E essa é uma mudança simples que você pode dar ao novo junior: ele pode fazer algo útil e poderá explorar a base de código ao mesmo tempo. ganha-ganha. Afinal, algo semelhante a esse padrão é bastante difundido. E agora você não precisa reescrever o código para usar lambdas ou qualquer coisa. (Nesse caso em particular, seria trivial, mas deixo pensando em exemplos em que isso seria difícil como exercício para o leitor.)

Observe que isso significa que a maneira como você fez isso é essencialmente uma maneira de lidar com o código herdado sem fazer reescritas caras. E o novo código?

Bem, no seu caso, onde você apenas deseja imprimir algo, basta:

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

O que é bastante simples e perfeitamente claro. O ponto que está subindo lentamente à superfície é que existem casos de uso para get () e isPresent (). Eles estão lá para permitir que você modifique o código existente mecanicamente para usar os tipos mais recentes sem pensar muito nisso. O que você está fazendo é, portanto, equivocado das seguintes maneiras:

• Você está chamando um método que pode retornar nulo. A idéia correta seria que o método retorne nulo.
• Você está usando os métodos bandaid herdados para lidar com isso opcional, em vez de usar os novos métodos saborosos que contêm fantasia lambda.

Se você deseja usar o Opcional como uma verificação simples de segurança nula, o que você deveria ter feito é simplesmente o seguinte:

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

Obviamente, a versão mais bonita disso se parece com:

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

A propósito, enquanto isso não é de forma alguma necessário, recomendo o uso de uma nova linha por operação, para facilitar a leitura. Fácil de ler e entender supera a concisão em qualquer dia da semana.

É claro que este é um exemplo muito simples, onde é fácil entender tudo o que estamos tentando fazer. Nem sempre é tão simples na vida real. Mas observe como, neste exemplo, o que estamos expressando são nossas intenções. Queremos OBTER o funcionário, OBTER seu ID e, se possível, imprimi-lo. Esta é a segunda grande vitória do Opcional. Isso nos permite criar um código mais claro. Eu também acho que fazer coisas como criar um método que faça um monte de coisas para que você possa alimentá-lo em um mapa é geralmente uma boa idéia.

Não vejo benefício no Estilo 2. Você ainda precisa perceber que precisa da verificação nula e agora é ainda maior, portanto menos legível.

Melhor estilo seria, se employeeServive.getEmployee () retornasse Opcional e o código se tornasse:

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

Dessa forma, você não pode chamar callemployeeServive.getEmployee (). GetId () e perceberá que deve lidar com valores opcionais de alguma forma. E se em todos os métodos de sua base de código nunca retornar nulo (ou quase nunca com exceções conhecidas por sua equipe a esta regra), isso aumentará a segurança contra o NPE.

Eu acho que o maior benefício é que, se a assinatura do método retornar um, Employeevocê não procurará nulo. Você sabe por essa assinatura que é garantido retornar um funcionário. Você não precisa lidar com um caso de falha. Com um opcional, você sabe que sim.

No código que eu vi, há verificações nulas que nunca falham, pois as pessoas não desejam rastrear o código para determinar se um nulo é possível; portanto, elas lançam verificações nulas em qualquer lugar defensivamente. Isso torna o código um pouco mais lento, mas, mais importante, torna o código muito mais barulhento.

No entanto, para que isso funcione, você precisa aplicar esse padrão de forma consistente.

Minha resposta é: simplesmente não. Pelo menos pense duas vezes sobre se é realmente uma melhoria.

Uma expressão (retirada de outra resposta) como

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

parece ser a maneira funcional correta de lidar com métodos de retorno originalmente anuláveis. Parece bom, nunca joga e nunca faz você pensar em lidar com o caso "ausente".

Parece melhor do que o estilo antigo

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

o que torna óbvio que pode haver elsecláusulas.

O estilo funcional

• parece completamente diferente (e é ilegível para pessoas que não estão acostumadas)
• é uma dor para depurar
• não pode ser facilmente estendido para lidar com o caso "ausente" ( orElsenem sempre é suficiente)
• induz a ignorar o caso "ausente"

Em nenhum caso, deve ser usado como uma panacéia. Se fosse universalmente aplicável, a semântica do .operador deve ser substituída pela semântica do ?.operador , o NPE esquecido e todos os problemas ignorados.

Embora seja um grande fã de Java, devo dizer que o estilo funcional é apenas um substituto pobre da declaração de um homem Java

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

bem conhecido de outras línguas. Concordamos que esta declaração

• não é (realmente) funcional?
• é muito semelhante ao código de estilo antigo, apenas muito mais simples?
• é muito mais legível que o estilo funcional?
• é amigável ao depurador?

Opcional é um conceito (um tipo de ordem superior) proveniente da programação funcional. Usá-lo acaba com a verificação nula aninhada e salva você da pirâmide da destruição.