Optional의 본질

자바에서 Optional이라는 건 어떤 존재여야 하는가? 라는 글을 본적이 있다.

+추가로 거기서 연결되는 StackoverFlow

Should Java 8 getters return optional type?

<aside> 💡 Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result", and using null for such was overwhelmingly likely to cause errors.

</aside>

스택오버플로우의 질문에서는, Getter 메서드에서도 Optional을 던져줘야하나? 라는 질문이었는데,

그에 대해서 Brian Goetz (자바 언어 설계자)가 답변한 말은 위와 같다. 정리하자면,

• Optional은 반환하는 결과값이 명백하게 결과가 없음 이라는 것을 명백하게 알릴때 쓰자.
• null일 가능성이 있으면 Optional.get을 호출하지 말라. → get을 getOrElseThrowSuchElementException과 같은 이름으로 불렀어야했다. 즉, get에 대한 설계가 잘못됐다. get은 Optional의 전체 목적을 훼손하는 메서드이다.
• 함수에서 값을 반환할 때 절대 null 이어서는 안되고 null이면 에러가 발생할 가능성이 높을 때 쓰자.
• 절대 Collection의 빈 컬랙션 리턴으로 대체하지 마라.
• 절대 parameter나 무언가의 field로써 사용하지 마라.
• Optional 객체 자신은 절대 null이어서는 안된다. 항상 Optional 인스턴스를 가리키고 있다.

추가정보

• Optional은 비싸다 - 일반 ref보다 x4 메모리를 차지한다. 간단한 비교라면 그냥 기존에 하던대로 하자.
• Optional은 Serializable이 아니다.

그래서 내가 이해한 바로 생각해본다면,

1. Optional을 쓴다는 것은 무언가를 return할 때 null 일 경우가 다분하다는 것이다. Optional은 이를 해당 메서드를 사용하는 사용자들에게 알리기 위해 쓰인다.

2. 그렇기 때문에 사용자는 Optional로 리턴되는 값에 대해 해당 Optional값에 get() 함수를 사용하면 안된다. 10의 9는 null일 수도 있으니까.

   (추가로 get을 호출하면 NoSuchElementException이 발생한다. 이게 있으면 null 체크 핸들링이랑 뭐가 다른지 사실 잘 모르겠다. 그래서 실제로도 isPresent() / get() pair은 bad reputation)

3. Optional은 객체이기 때문에 비싸다. 그래서 그냥 값을 가져오는거면 null 체크 로직 기존대로 쓰자.

정리를 다 해본 지금도 조금은 아리까리하긴 하다. 처음 설계에서 get이라는 메서드의 의도를 잘못 설계했던만큼 나도 헷갈리는게 아닌가 싶은 생각이 든다.

추가로 Optional에 대한 주의사항을 한번 살펴보는 것도 좋을 것 같다.

→ https://dzone.com/articles/using-optional-correctly-is-not-optional

public String pwd() {
	return fetch().orElse("none");
}

public Optional<String> fetch() {
	... 
}

// 또는, 지금의 우리라면?
public String pwd() {
	return fetch() != null ? fetch() : "none"
}

public String fetch() {
	... 
}