Java에서 Kotlin으로

22장. 클래스에서 함수까지

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

객체 지향 프로그래머는 유형을 만들어 문제를 해결하는 데 능숙합니다. 함수형 프로그래머는 기존 유형을 함수로 보강하는 경향이 있습니다. 새로운 유형을 정의하지 않고 얼마나 멀리 갈 수 있을까요?

15장, '별칭을 입력하는 캡슐화된 컬렉션'에서는 원시 컬렉션으로 작업할 때의 이점을 살펴보고 16장, ' 함수에 대한 인터페이스'에서는 새로운 함수 유형을 만드는 대신 기본 제공 함수 유형을 사용하는 방법을 살펴보았습니다. 이 장에서는 지금까지 배운 내용을 적용하여 처음부터 Kotlin을 작성해 보도록 하겠습니다.

요즘처럼 REST API와 웹후크를 사용하는 시대에도 자동화된 B2B 커뮤니케이션의 대부분은 SFTP(Secure File Transfer Protocol)로 교환되는 표 형식의 텍스트 데이터입니다. Travelator는 캠핑장 위치, 관심 지점, 미결제 청구서 등에 대한 데이터를 일정한 행과 열로, 열 구분자를 다르게, 나머지 행의 열 이름을 지정하는 헤더를 사용하거나 사용하지 않고 모두 가져와야 합니다. 20장( )에서 한 팀에서는 자체 구문 분석기를 만들었고, 다른 곳에서는 신뢰할 수 있는 Apache Commons CSV 라이브러리를 사용했습니다. 솔직히 대부분의 용도에서 Commons CSV는 즉시 작동하고 특수한 경우에 맞게 멋지게 구성할 수 있으며 Kotlin과 잘 작동하기 때문에 여전히 사용하고 있습니다.

오늘은 클린룸 Kotlin 구문 분석기가 어떤 모습일지 살펴보겠습니다. 완료되면 우리가 만든 것을 Commons CSV 기능과 비교하여 Java와 Kotlin의 곡물이 어떻게 다른 API와 구현으로 이어지는지 살펴볼 것입니다.

수락 테스트

이전 챕터에서 알 수 있듯이 트래블러 개발자는 익스트림 프로그래머입니다(익스트림 프로그래밍 설명: 변화 수용). 우리는 먼저 높은 수준의 승인 테스트부터 시작하여 코드 테스트를 작성합니다. 테이블 리더를 작업 중이므로 스텁 메서드가 있는 TableReaderAcceptanceTests 클래스를 생성하고 실행되는지 확인합니다:

class TableReaderAcceptanceTests {
    @Test
    fun test() {
    }
}

예제 22.1 [table-reader.1:src/test/java/travelator/tablereader/TableReaderAcceptanceTests.kt] (diff)

실행이 되니(심지어 통과도 합니다!) 이제 제대로 코딩을 시작할 수 있습니다.

수락 테스트의 임무 중 하나는 인터페이스의 모양을 결정하는 것입니다. 그동안 몇 개의 파일을 파싱해 본 결과, 거의 항상 파일을 읽고 각 (헤더가 아닌) 행마다 하나씩 특정 도메인 유형의 값 목록을 반환하는 것이 필요하다는 것을 알고 있습니다. 도메인 유형을 Measurement 으로 설정하고 이를 테스트로 스케치해 보겠습니다:

class ...