job4j.ru - Практика. Ревью. Результат.

Осознал Kotlin спустя 7 лет

Когда я начинал изучать Kotlin, то первое, что было написано в книге, — что Kotlin – это выразительный и лаконичный язык.
Слушая эти заветы, я старательно пытался реализовать DSL. Код самого DSL получался коротким, но реализация этого DSL вызывала сомнения.

Пример:

fun <E> select(pool: BasicDataSource, sql: String,
               ext: (ResultSet) -> E,
               params: ArgStatement.() -> Unit): List<E> {
    val rsl = ArrayList<E>()
    pool.connection.use { cn ->
        cn.prepareStatement(sql).use { st ->
            val args = ArgStatement(st)
            params(args)
            val set = st.executeQuery()
            while (set.next()) {
                rsl.add(ext.invoke(set))
            }
        }
    }
    return rsl
}

// Использование
fun findByListId(levIds: Set<Int>): List<Level> =
        select(pool, "SELECT * FROM level WHERE id = ANY(?)") {
            arg(levIds)
        }

И в SQL всё понятно: SQL – это декларативный язык, то есть мы описываем результат работы, а не саму работу.
Но когда дело доходило до того, что нужно мне (а это бизнес-процесс), я не знал, что делать.

Дело в том, что сама идея DSL сомнительная. Мне нужно сначала создать конструктор, а только потом писать проект. Я не хочу так. Я хочу сразу писать код, а ещё лучше – писать его меньше.
Как оказалось, всё упиралось в класс. Ответьте на вопрос: что является главным элементом языка Java? Объекты, методы? Нет, главный элемент – это класс. Всё живёт в нём. Парадигмы программирования – это не о классе, но в Java всё крутится вокруг класса, и из-за этого возникают проблемы многословности и многослойности.

Точно так же я и стал писать код на Kotlin: везде должен быть класс, даже если у него нет состояния. Причём такие примеры есть в самом языке Kotlin, например библиотека KoTest, DSL для тестирования.

Я сейчас дочитал только половину книги по микросервисам на Go, но мне сразу бросилось в глаза, что они не думают в рамках класса. Их там вовсе нет.
Я решил попробовать сделать так же.

У меня есть эталонное задание в курсе job4j ToDo-лист.
Для тех, кто не учился у меня, я опишу здесь архитектуру в рамках классов:
- StartUI – класс, который занимается графикой;
- Menu – класс, отвечает за управление меню;
- Action – классы, реализующие поведение меню;
- Store – хранилище для задач;
- Task – задачи.

И в Java-курсе, и в Kotlin-курсе я описывал эту задачу через классы.
И вроде бы всё логично.
StartUI зависит от Menu, Menu зависит от Action, Action от Task. Внедряй зависимости и полетел.

Если мы оценим код с позиции состояний, то поймём, что кроме Store и Task у нас нет реальных объектов.
StartUI, Menu, Action – это просто линейные операции без состояний.
То есть мне не надо писать лишний код, а только сфокусироваться на бизнес-процессе.

Ниже я опишу, как я его переделал.

Классы, которые действительно содержат состояния и от которых нельзя уйти:

data class Task(
    val ID: Int,
    val name: String
)

class Store {
    private val mem = ArrayList<Task>()

    fun add(task: Task) {
        mem.add(task)
    }

    fun findById(ID: Int): Task? =
        mem.find { it.ID == ID }
}

А теперь то, что не классы и объекты, я описал функциями:

fun startUI(input: (String) -> String, menu: Map<Int, () -> Boolean>) {
    var selected = 0
    do {
        selected = input("Select: ").toInt()
        val act = menu[selected] ?: continue
        if (!act()) {
            println("Error")
        }
    } while (selected != 0)
}

Обратите внимание, что эта функция не зависит от пользовательского кода или объектов. То есть весь код – это core. Я могу его протестировать, как угодно.

Второй момент, и я считаю его очень важным. Если это был бы класс, то я мог туда добавить ещё методы, а сейчас я ограничен только поведением моего меню. Никто не сможет запустить сюда грязные ручонки и дописать ещё методы. То есть за счёт языка я ограничил возможность раздувать код.

🔥5

535 views16:29