Java에서 Kotlin으로

6장. Java에서 Kotlin 컬렉션으로의 전환

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

겉으로 보기에 Java와 Kotlin은 매우 유사한 컬렉션 라이브러리를 가지고 있으며 의심스러울 정도로 원활하게 상호 운용됩니다. 차이점은 무엇이고, 그 동기는 무엇이며, Java에서 Kotlin 컬렉션으로 이동할 때 주의해야 할 점은 무엇일까요?

Java 컬렉션

5장에서는 Java가 객체를 기본적으로 상태 저장 및 변경 가능한 것으로 보던 시절에 어떻게 성장했는지 살펴보았습니다. 특히 컬렉션의 경우, 추가할 수 없다면 목록이 무슨 소용이 있을까요? 우리는 빈 컬렉션을 만들고 거기에 추가하는 방식으로 컬렉션을 구축합니다. 장바구니에서 항목을 제거해야 한다면 목록을 변경하고 카드 팩을 섞으면 당연히 덱의 순서가 바뀌겠죠. 우리는 우유가 필요하거나 고양이를 동물 병원에 데려갈 때마다 새로운 종이 할 일 목록을 만들지 않을 것입니다. 변경 가능한 컬렉션은 우리의 실제 경험을 반영합니다.

출시 당시 내장 컬렉션의 품질은 Java를 채택한 좋은 이유였습니다. 당시 많은 언어에는 표준 라이브러리에 크기 조정이 가능한 컬렉션이 없었습니다. 객체 기술을 통해 변경 가능한 컬렉션을 안전하게 정의하고 사용할 수 있었습니다. 이제 이 강력한 기능을 사용하는 것이 당연했기 때문에 우리는 Sun의 의도대로 Vector 및 HashTable 을 사용했습니다. 즉, 생성한 다음 변경했습니다. 모든 생성자가 빈컬렉션을 생성했기 때문에 선택의 여지가 없었어요.

Java 2(Java가 C# 버전 번호와 경쟁해야 할 때까지는 1.2 버전이었다)는 개정된 컬렉션 라이브러리를 도입했습니다. 이는 임시적인 Vector, Stack, Hashtable 클래스를 정리하고 ArrayList 및 HashSet 와 같은 보다 유용한 구현이 포함된 공통 Collection 인터페이스를 만들었습니다. 이제 컬렉션을 다른 컬렉션의 복사본으로 만들 수 있게 되었습니다. 정적 Collections 클래스는 sort 및 reverse 과 같은 유용한 유틸리티 작업을 제공했습니다. Java 5는 제네릭을 도입하고 이를 기존 컬렉션에영리하게 개조하여 이제 List<Journey> 과 같은 유형을 선언할 수 있게 되었습니다.

Java 컬렉션은 여전히 변경 가능하지만 매우 변경 가능했습니다. 항목을 추가하고 제거하는 연산뿐만 아니라 정렬과 같은 연산도 변경으로만 정의되어 있으며, List 의 정렬된 복사본을 반환하는 표준 라이브러리 함수는 없습니다.

계속 말하겠지만, 돌연변이는 한 곳의 상태가 다른 곳의 상태와 동기화되지 않을 수 있기 때문에 복잡성 관련 문제의 많은 원인이 됩니다. 예를 들어 Travelator에서는 경로를 List 의 Journey 로 나타낼 수 있습니다. 고통 점수라는 개념도 있습니다. 고통 점수가 낮을수록 더 쾌적한 경로일 가능성이 높습니다. 다음은 경로의 고통 점수를 계산하는 방식입니다: ...