dpwns523
commented
1 year ago 답변
형식을 명시적으로 해야 하는지, 컴파일러가 형식 검사, 추론이 가능하니 생략을 할 지에 대한 고민이라고 생각했습니다. 답이 정해진 것이 아니어서 제 주관을 정리해볼게요!
우선 컴파일러가 형식을 검사하고 추론하는 과정을 정리해놓은 블로그1, 블로그2를 보시면 도움 될 것 같습니다!
처음 생각은 상황에 따라 다르지만 해석하기 어려운 경우가 있을까? 라는 생각을 했습니다 예시를 만들어보면
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
....
numbers.stream().sorted((n1, n2) -> n1 - n2); 라는 방식으로 사용하는 경우가 많았고, 개발자 입장에서도 금방 이해할 수 있다고 생각하고 있었습니다. 하지만 결국 코드를 쭉 읽다보면 컴파일러가 형식을 추론하듯이 n1, n2가 보이는 시점에 numbers를 볼 것이고, numbers를 찾아 타입이 무엇인지 확인하게 됩니다.
또 다른 예로 프로젝트에서 비즈니스 로직이 복잡해진 경우를 보면, 같은 u지만 중간에 객체가 변환될 수 있고, 그 객체의 멤버 변수를 확인해보는데도 어려움이 있을 수 있습니다. (예시 코드는 사용되는 코드는 아니고 제가 일부러 복잡하게 만들어봤습니다)
public Map<Long, FollowedType> getFollowTypesByUserId(Long userId, String search){
List<User> users = userRepository.searchByName(search);
// 비즈니스 로직
return users.stream()
.filter(u -> u.getType() == UserType.NORMAL)
.map(u -> UserMapper.INSTANCE.toUserResponse(u, userId))
.filter(u -> u.postCount > 100)
.filter(u -> u.reviewCount > 100)
.map(Collectors.toMap(UserResponse::getId, this::getFollowType);
}
public FollowType getFollowType(UserResponse userResponse) {
return userResponse.getFollowId() == null ? FollowType.NONE : FollowType.FOLLOWED;
}마찬가지로 코드를 읽다 보면 중간 중간 원본 데이터를 보게 되고, UserResponse로 변환해버리면 UserResponse의 멤버를 확인하려고 추가적인 작업이 이뤄진다고 생각됩니다.
무엇보다 어떤 상황에서 타입을 생략하는 것이 낫고, 어떨 때 안 하는 것이 나을지를 고민하던 도중 친절해서 나쁠 것이 없다는 생각이 떠올라서 저는 앞으로 생략하지 않는 방법을 고려해볼 것 같습니다.
hgene0929
문제
컴파일러의 형식 추론으로 인해 람다표현식에서 매개변수의 타입 생략이 가능합니다. 어떤 상황에서 타입을 생략하는 것이 낫고, 어떨때 안하는 것이 나을까요..?
contents - 세부 내용
읽어보다가 상황에 따라 다르다~ 고 끝난것같아서 올려봅니다!