Java에서 Kotlin으로

18장. 비공개 클래스 공개

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

시스템은 유형과 연산, 명사와 동사로 구성됩니다. Java에서 명사는 클래스와 인터페이스로, 동사는 메서드로 표현되지만 Kotlin은 밀폐형 클래스 계층 구조와 독립형 함수를 추가합니다. 어떤 이점을 제공할까요?

변화 는 소프트웨어 설계의 끊임없는 과제입니다. 사람들이 소프트웨어를 더 많이 사용할수록 소프트웨어가 수행하기를 바라는 일이 더 많아집니다. 새로운 사용 사례를 지원하려면 기존 데이터 유형과 함께 작동하는 새로운 기능을 추가하고 기존 기능과 함께 작동하는 새로운 데이터 유형을 추가해야 합니다. 설계가 소프트웨어의 발전 방향에 잘 맞춰져 있다면 새 코드를 추가하고 기존 코드를 약간만 변경하여 새로운 기능을 추가할 수 있지만, 그렇지 않다면 새 데이터 유형을 추가할 때 많은 기능을 변경하거나 함수를 추가해야 할 때 많은 데이터 유형을 변경해야 할 것입니다.

데이터 유형과 함수의 가변성 사이의 긴장은 도메인 모델의 핵심 개체에서 가장 극명하게 느껴집니다. 예를 들어 여행자의 여정은 Travelator 애플리케이션의 핵심 개체입니다. 애플리케이션의 많은 기능이 여정에 대한 정보를 보거나 내용을 변경하거나 계산하는 기능을 제공합니다. 따라서 사용자의 많은 기능 요청이 Itinerary 유형에 영향을 주는 것은 당연한 결과라고 할 수 있죠. 여행객들은 10장에서 살펴본 것처럼 여정과 숙박뿐만 아니라 이제는 경로에 있는 레스토랑 예약과 명소 등 더 많은 종류의 것들을 여정에 포함하기를 원합니다. 또한 여정을 통해 더 많은 일을 하고 싶어 합니다. 14장에서는 비용을 추정하는 방법을 살펴보았지만 고객들은 비용, 시간 또는 편의성별로 비교하고, 지도에서 보고, 달력으로 가져오고, 친구들과 공유하고 싶어 하는 등 상상력은 끝이 없습니다.

지난 14장에서 Itinerary 클래스를 살펴봤을 때 여정을 데이터 클래스로 모델링하면서 경로에 대한 속성과 경로를 따라 필요한 숙박 시설에 대한 속성을 사용했습니다:

data class Itinerary(
    val id: Id<Itinerary>,
    val route: Route,
    val accommodations: List<Accommodation> = emptyList()
) {
    ...
}

예제 18.1 [accumulator.17:src/main/java/travelator/itinerary/Itinerary.kt] (diff)

Itinerary 그 이후로 애플리케이션에 더 많은 기능을 추가하면서 여정에 더 많은 유형의 항목이 추가되었습니다. 각 유형의 여정 항목을 별도의 컬렉션에 보관하는 것이 점점 더 번거로워지는 것을 느꼈습니다. 너무 많은 코드가 이러한 컬렉션을 결합하거나 별도의 컬렉션에 동일한 필터와 변환을 적용해야 했기 때문입니다. 그래서 각 유형의 항목을 별도의 컬렉션에 보관하지 않고 ItineraryItem 단일 컬렉션으로 유지하기로 ...