전통적인 널 포인터 검사 대신 Java 8+에서 Optional을 사용하는 이유는 무엇입니까?

우리는 최근에 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

요점은 직원이 아닌 직원 서비스 가 있다는 것을 알고 있으므로 with로 마무리 할 수 ​​있다는 것 입니다 . 그런 다음 전화를 걸면 직원을 얻거나 얻지 못할 수 있습니다. 그 직원은 신분증을 가지고있을 수도 있습니다. 그런 다음 ID로 끝나면 인쇄하려고합니다.OptionalOptional.of()getEmployee()

명시 적으로 확인 할 필요가 없습니다 어떤 이 코드 등을 널 (null), 존재는.

Optional단일 값 을 갖는 추가 값이 없습니다 . 보시다시피, 그것은 null수표를 존재 여부 확인으로 대체합니다 .

이 거대한 가진 부가가치 Collection같은 것들입니다. 구식 저수준 루프를 대체하기 위해 도입 된 모든 스트리밍 방법은 Optional사물을 이해 하고 그에 대한 올바른 일을 수행합니다 (처리하지 않거나 궁극적으로 다른 unset 반환 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에 대한

널 리턴 API 메소드를 사용할 때 필요할 때 값을 생성하여 존재하지 않는 값을 피하십시오.

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다른 사람에 의해 제공합니다.

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

가장 큰 실수는 여전히 더 절차적인 용어로 생각하고 있다는 것입니다. 이것은 사람으로서 당신을 비판하는 것이 아니라 단지 관찰 일뿐입니다. 보다 기능적인 용어로 생각하는 것은 시간과 연습이 필요하기 때문에 메소드가 현재 존재하고 가장 분명한 것처럼 보일 것입니다. 이차적 인 사소한 실수는 메소드 내부에서 Optional을 생성하는 것입니다. 선택 사항은 어떤 것이 값을 반환하거나 반환하지 않을 수 있음을 문서화하는 데 도움이됩니다. 아무것도 얻지 못할 수도 있습니다.

이것은 당신이 완벽하게 합리적으로 보이는 완벽하게 읽을 수있는 코드를 작성하도록 이끌었지만, 당신은 get and isPresent 인 사악한 쌍둥이 유혹에 유혹을 받았습니다.

물론 문제는 빨리 "현재 존재하는 이유는 무엇입니까?"

많은 사람들이 여기서 놓친 것은 isPresent ()는 gosh-darn 유용한 람다가 얼마나 기능적이며 기능적인 것을 좋아하는 사람들이 완전히 탑승 한 사람들이 작성한 새로운 코드를 위해 만들어진 것이 아니라는 것입니다.

그러나 그것은 우리에게 몇 가지 좋은, 위대하고 매력적인 (?) 이점을 제공합니다.

• 새로운 기능을 사용하기 위해 레거시 코드를 쉽게 전환 할 수 있습니다.
• Optional의 학습 곡선을 완화합니다.

첫 번째는 다소 간단합니다.

다음과 같은 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이 출시되었으며 우리는 탑승을 시작했습니다. 따라서 우리가하는 일 중 하나는 이전 인터페이스를 Optional을 반환하는 것으로 교체하고 싶다는 것입니다. 왜? 다른 사람이 이미 은혜롭게 언급 한 것처럼 : 이것은 무언가가 null 일 수 있는지의 여부를 추측합니다 . 이것은 이미 다른 사람들에 의해 지적되었습니다. 그러나 지금 우리는 문제가 있습니다. 우리가 (무고한 방법으로 alt + F7을 치는 동안 실례합니다), 그렇지 않으면 훌륭한 일을하는 잘 테스트 된 레거시 코드 에서이 방법이 호출되는 곳을 상상해보십시오. 이제이 모든 것을 업데이트해야합니다.

이 곳은 isPresent가 빛나는 곳입니다.

지금 : Snickers lastSnickers = snickersCounter.lastConsumedSnickers (); if (null == lastSnickers) {throw new 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을 반환 할 수있는 메서드를 호출하고 있습니다. 올바른 아이디어는 메소드가 널을 리턴한다는 것입니다.
• 람다 환상을 포함하는 맛있는 새로운 방법을 사용하는 대신 레거시 반창고 방법을 사용하여이 옵션을 처리합니다.

Optional을 간단한 null 안전 검사로 사용하려면 다음을 수행해야합니다.

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

물론 이것의 좋은 버전은 다음과 같습니다.

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

그건 그렇고, 꼭 필요한 것은 아니지만 작업마다 새로운 줄을 사용하는 것이 더 쉽기 때문에 읽기 쉽습니다. 읽기 쉽고 이해하기 쉬운 요일 간결함.

이것은 물론 우리가하려는 모든 것을 이해하기 쉬운 매우 간단한 예입니다. 실생활에서 항상 간단한 것은 아닙니다. 그러나이 예에서 우리가 표현하고있는 것이 우리의 의도라는 점을 주목하십시오. 우리는 직원에게 GID와 ID를 부여하고 가능하면 인쇄하고 싶습니다. 이것은 Optional의 두 번째 큰 승리입니다. 보다 명확한 코드를 만들 수 있습니다. 또한 맵에 피드를 제공 할 수 있도록 많은 것들을 수행하는 메소드를 만드는 것과 같은 일을하는 것이 일반적으로 좋은 생각이라고 생각합니다.

Style 2에는 이점이 없습니다. 여전히 null 확인이 필요하다는 것을 알아야합니다. 이제는 더 크므로 읽을 수 없습니다.

employeeServive.getEmployee ()가 Optional을 반환하면 코드는 다음과 같이됩니다.

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

이렇게하면 employeeServive.getEmployee (). getId ()를 호출 할 수 없으며 어떻게 든 선택적 valoue를 처리해야합니다. 그리고 전체 코드베이스 메소드에서 null을 반환하지 않거나 팀에 예외 가이 규칙에 대해 거의 알려지지 않은 경우) NPE에 대한 안전성이 향상됩니다.

나는 가장 큰 장점은 당신의 방법 서명이를 반환하는 경우이다 생각 Employee이 없는 널 (null)을 확인합니다. 그 서명으로 직원을 돌려주는 것이 보장된다는 것을 알고 있습니다. 장애 사례를 처리 할 필요가 없습니다. 옵션으로 당신은 알고 있습니다.

내가 보았던 코드에는 사람들이 null을 사용할 수 있는지 여부를 결정하기 위해 코드를 추적하지 않기 때문에 결코 실패하지 않는 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

원래 nullable 반환 메서드를 처리하는 올바른 기능적 방법 인 것 같습니다. 그것은 멋지게 보이고 결코 던져 지지 않으며 결코 "부재"사례를 처리하는 것에 대해 생각하게하지 않습니다.

예전 방식보다 낫다

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

else절이 있을 수 있습니다 .

기능적인 스타일

• 완전히 다른 것처럼 보임 (사용하지 않는 사람은 읽을 수 없음)
• 디버깅이 어렵다
• "결석"사례를 처리하기 위해 쉽게 확장 할 수 없음 ( orElse항상 충분하지는 않음)
• "결석"사례를 무시하도록 오도

어떤 경우에도 만병 통치약으로 사용해서는 안됩니다. 그것이 보편적으로 적용 가능하다면, .오퍼레이터의 시맨틱은 ?.오퍼레이터 의 시맨틱으로 대체되어야 하고, NPE는 잊혀지고 모든 문제는 무시된다.

큰 자바 팬이지만 기능적 스타일은 그저 자바 사람이 그 진술을 대신하는 것이라고 말합니다.

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

다른 언어에서 잘 알려져 있습니다. 우리는이 진술에 동의합니까?

• (실제로) 기능하지 않습니까?
• 구식 코드와 매우 유사합니다. 훨씬 간단합니까?
• 기능적 스타일보다 훨씬 더 읽기 쉬운가?
• 디버거 친화적입니까?

선택적은 함수형 프로그래밍에서 나오는 개념 (고차 형)입니다. 그것을 사용하면 중첩 된 null 검사가 없어지고 피라미드의 운명에서 벗어날 수 있습니다.