기본 유형을 과도하게 사용하는 위험
1742 단어 kotlinsoftwareengineering
저는 초기부터 Java의 기본 유형이 가장 성능이 뛰어나며 가능하면 이를 선호해야 한다고 배웠습니다.
이것은 사실이지만 기본 유형은 일반 객체보다 훨씬 가볍기 때문에 이를 과도하게 사용하면 다른 종류의 문제가 발생합니다. 거의 모든 것을 문자열과 숫자의 조합으로 표현할 수 있습니다. 예를 들어, 사용자 또는 사용자가 소유한 엔터티(예: 블로그 게시물)의 ID를 나타내야 하는지 여부에 관계없이
long
를 사용할 수 있습니다.이것은 무해해 보일 수 있지만 매우 오류가 발생하기 쉽습니다. 사용자를 제거하는 메서드와 사용자가 소유한 엔터티를 제거하는 다른 메서드가 있으면 예제에서 모두
long
를 허용합니다.fun deleteUser(long userId) {
[...]
}
fun deleteBlogPost(long postId) {
[...]
}
누군가 혼동하여 잘못된 id 유형을 전달하는 경우 최상의 시나리오는 런타임에 오류가 발생하고 최악의 시나리오는 잘못된 항목이 삭제되는 것입니다(두 네임스페이스에 동일한 id를 가진 개체가 있다고 가정) ). 이와 같이 오류가 발생하기 쉬운 상황이 식별되면 사전 조치를 취하고 이를 방지할 수 있는 방법을 설정하는 것이 좋습니다.
이러한 유형의 오류에 대한 쉬운 해결책이 있습니다. 기본 유형을 래핑하여 도메인별 유형을 생성합니다. 이전 예에서
UserID
를 포함하는 BlogPostId
및 long
클래스를 가질 수 있습니다.fun deleteUser(UserId userId) {
[...]
}
fun deleteBlogPost(BlogPostId postId) {
[...]
}
이렇게 하면 사용자를 삭제하는 방법과 게시물을 삭제하는 방법이 서로 다른 매개변수 유형을 갖게 됩니다. 잘못된 종류의 ID가 전달되는 혼란의 경우 컴파일 시간에 포착됩니다.
물론 이 접근 방식을 사용하면 성능이 저하됩니다. 개체의 래핑 및 래핑 해제에는 몇 밀리초가 더 소요됩니다. 애플리케이션이 성능에 민감하지 않다면 비용을 들일 가치가 있다고 생각합니다. 그렇지 않은 경우 이 문제를 정확히 해결하도록 설계된 기능Kotlin inline classes 및 곧 출시될 기능Java inline classes을 살펴보십시오.
즐거운 코딩하세요!
Reference
이 문제에 관하여(기본 유형을 과도하게 사용하는 위험), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/rockandnull/the-danger-of-overusing-primitive-types-5a41텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)