Optional에 대하여

 

핑이 발표한거 적었습니다.

 

Optional을 도입할 만큼 Null을 핸들링할 만큼 Null은 NPE를 발생시키고 애플리케이션에 위험을 발생시킬 수 있음.

Null이라는 문제를 줄이기 위해 Optional을 사용하면 좋겠고, 가장 중요한건 불필요하게 Null을 만들지 않는게 중요함.

값이 절대적으로 존재함에도 불구하고 Boxing을 쓰곤 함. 이런게 꼼꼼한 개발자일수록 불필요한 null에 대한 고려를 하게 됨.

 

 

- Optional이 Serializable을 구현하지 않아서 필드에 부적합함

- argument에도 적합하지 않음. 필요하면 JSR 305의 @Nullable 사용할 것 -> 정적분석기에 hint를 줌

- Optional은 공짜가 아님. 성능이 진~짜 중요한 부분에서는 Optional을 지양하기도 함

- 처리를 강제하기 때문에 개발자 성향에 따라 Optional을 싫어할 수 있음. 다만 Public한 시그니처에서는 매우 유용하다고 생각함

(시그니처에 리턴값이 null일 수 있음을 표현하기에 계약 관점에서일듯)

 

 

26가지 Optional 내용들

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

26 Reasons Why Using Optional Correctly Is Not Optional - DZone

 

- Optional이 시그니처인데, null을 반환하면 안된다.

- get을 부르기 전에는 값이 존재하는지 확인하자.

- java 버전이 올라가면서 Optional에 적용된 유려한 함수를 사용하자.

- 가끔씩 코드를 보면, if statement로 null확인을 피하기 위해, 코드 내부에서 Optional을 만들고 Optional의 map같은 걸 쓰는 함수가 있는데, Optional이 비용이 있기 떄문에 if statement로 쓸 수 있는건, 쓰자.

- Optional은 반환값이 null일 수 있다는 개념을 표현한거기 때문에 if문의 흐름제어를 위해 쓰이는건 적절하지 않다. 

- 컬렉션을 Optional을 감싸는 경우가 있는데, 컬렉션도 마찬가지로 자기가 비어있다는 개념을 표현할 수 있기에 null을 반환하기 보다 empty를 반환하기를 권장함. 우리가 만든 클래스라고 하더라도, isEmpty()가 있어서 값이 없음을 표현할 수 있으면 Optional을 쓰지 않아도 될듯(ex. 일급컬렉션이라서 값이 없음을 표현할 수 있다면 옵셔널 안써도 될듯)

- 값이 없을수도 있다는 개념이 Optional없이도 표현됨에도 불구하고 불필요하게 Optional로 래핑하게 됨. 다만 예외적인 걸 생각해볼 수 있는데, 3rd파티가 구현한 라이브러리에 key-value타입으로 캐시에 대한 값을 저장할 수 있을 때. 특정 구현체들은 값이 null인 것을 허용하지 않음. 하지만 비즈니스 관점에서는 값이 null인게 캐시의 대상이 될 수 있음. 이런 경우 값의 객체가 스스로 비어있다는 것을 표현할 수 없다면 이런 경우엔 값 타입을 Optional로 감싸서 저장하는거 괜찮지 않나 생각함

- primitive 타입에 대해 boxing을 해야할 때가 있는데 OptionalInt, OptionalDouble, OptionalLong을 만들어놨음 (불리언, byte는 없음)

- Optional을 사용할 때, Equlity를 비교하기 위해 값을 꺼낼 필요가 없음. Optional자체가 value-based 클래스이기 때문임.