Java to Kotlin

Chapter 22. Classes to Functions

Object-oriented programmers are adept at solving problems by creating types. Functional programmers tend to augment existing types with functions. How far can we go without defining new types?

In Chapter 15, Encapsulated Collections to Type Aliases, we saw the advantages of working with raw collections, and in Chapter 16, Interfaces to Functions, we looked at using built-in function types rather than creating new ones. In this chapter, we’ll apply the lessons we’ve learned to write some Kotlin from scratch.

Even in these days of REST APIs and webhooks, much of automatic business-to-business communication is in the form of tabular text data exchanged by Secure File Transfer Protocol (SFTP). Travelator has to import data for campsite locations, points of interest, unsettled bills, and more, all in regular rows and columns, with different column separators, and with and without a header naming the columns for the remaining rows. In Chapter 20, we saw that one team had created its own parser; in other places, we use the tried-and-trusted Apache Commons CSV library. Honestly, for most uses, we would still use Commons CSV, because it works out of the box, is nicely configurable for special cases, and plays really well with Kotlin.

Today though we’re going to see what a clean-room Kotlin parser would look like. When we’re done, we’ll compare what we come up with to the Commons CSV functionality so that we can see how the grains of Java and Kotlin lead ...