Optional을 메소드 인자로 사용하는 것이 권장되지 않는 이유
개요
Optional 클래스를 사용하면 데이터를 래핑하고 null 체크와 일부 try-catch 블록을 피할 수 있다. 이를 통해 메소드 호출을 체인으로 연결하고 더 유연한 코드를 작성할 수 있다. 그러나 남용하면 성능 저하와 코드의 복잡성을 초래할 수 있다. 이 글에서는 null 값으로부터 보호가 필요한 몇 가지 일반적인 사용 사례를 살펴본다.
public Account get(String username);
public Optional<Account> find(String username);1. 메소드 반환 타입으로서의 Optional 👍
Optional을 사용하여 null일 가능성이 있는 데이터를 반환하는 것은 널리 채택된 방법이다. 호출자는 결과가 null일 수 있다는 것을 인지하게 되며, 추가 검사를 수행할 때 유용하다.
2. 게터 래핑 👍
Optional<Membership> getMembershipOptional() {
return Optional.ofNullable(membership);
}게터가 Optional을 반환하게 하는 것은 null이 유효한 값인 필드에 대해 좋은 관행이 될 수 있다. 다만 DTO 객체에는 적용하지 않는 것이 좋다.
3. 매우 단순한 로직에 대한 로컬 변수 래핑 👎
단순한 작업을 위해 Optional을 사용하는 것은 일반적인 안티 패턴이다.
Optional.ofNullable(account)
.ifPresent(acc -> processAccount(acc));이 경우, 고전적인 null 체크가 더 적절하다:
if (account != null) {
processAccount(account);
}4. Optional 필드와 메소드 파라미터 👎
Optional을 클래스 필드나 메소드 파라미터로 사용하는 것은 권장되지 않는다. 이는 성능 저하를 초래할 수 있으며, Optional 클래스는 직렬화가 불가능하다.
createAccount(String userName, Optional<Membership> membership)대신 메소드를 오버로드하여 파라미터를 검증하는 것이 더 좋다:
createAccount(String userName);
createAccount(String userName, Membership membership);결론
Optional 클래스는 도메인 모델에 표현력을 제공하고 안전성을 높일 수 있다. 그러나 남용하면 나쁜 설계와 코드 복잡성을 초래할 수 있다. 팀 내에서 확실한 규칙을 세우고 적절한 코드 리뷰를 통해 Optional은 유용하게 활용될 수 있다.
- 의미의 오용:
Optional은 반환 값이 있을 수도 없을 수도 있는 상황을 표현하기 위해 설계되었다. 메소드 인자로 사용하면 본래 목적과 맞지 않다. - 불필요한 복잡성 증가:
Optional을 인자로 사용하면 코드의 복잡성이 증가하고 가독성과 유지보수성이 저하된다. - 표준 관례 위반: 자바 커뮤니티에서는
Optional을 반환 타입으로 사용하는 것이 관례다. 인자로 사용하는 것은 표준 관례를 위반하는 것이다.
-참고-
https://stackoverflow.com/questions/31922866/why-should-java-8s-optional-not-be-used-in-arguments
https://medium.com/javarevisited/4-reasons-why-you-should-use-java-optional-or-not-4e44d51a9645
