🏝 Как делать минималистичный API интерфейс с помощью extension fun

При разработке библиотек на Kotlin одним из элегантных решений является подход, знакомый многим по Flow из Coroutines. Его суть в том, что интерфейс содержит только базовый, фундаментальный метод, а все остальные операторы реализованы как функции-расширения.

Например, интерфейс Flow из Kotlin выглядит так:

interface Flow<out T> {
    suspend fun collect(collector: FlowCollector<T>)
}

fun interface FlowCollector<in T> {
    suspend fun emit(value: T)
}

Почему это хороший подход?
👉 Минимализм и ясность интерфейса. Один метод в интерфейсе ясно показывает суть контракта, облегчает понимание и поддержку.
👉 Гибкость расширения API. Можно добавлять бесконечное количество новых операторов без изменения интерфейса и нарушения обратной совместимости.
👉 Удобство и читаемость. Цепочки вызовов выглядят компактно, легко читаемы и следуют единому стилю, принятому в Kotlin.

Плюсы подхода
✅ Простое масштабирование библиотеки, благодаря гибкости Kotlin Extension-функций.
✅ Лёгкость в написании и поддержке тестов, так как расширения можно тестировать отдельно.
✅ Улучшение читаемости клиентского кода благодаря последовательной и понятной структуре вызовов.
✅ Простые и понятные API интерфейсов в типах

Минусы подхода
⚠️ Сложность в управлении видимостью и областью применения расширений. Пользователь может запутаться в большом количестве операторов.
⚠️ Ограничение на возможность переопределения методов. Расширения не переопределяются, что может осложнить кастомизацию.

Когда лучше использовать методы интерфейса вместо расширений?
Обычно в интерфейс стоит помещать:
👉 Фундаментальные методы, которые описывают самую суть интерфейса.
👉 Методы, для которых критично переопределение и которые могут требовать разных реализаций в разных имплементациях.
👉 Функции, критичные к производительности, так как их реализация через расширения иногда менее эффективна.

Когда методы стоит делать как расширения
Явными кандидатами для функций через расширения к интерфейсу - те что имеют реализацию по умолчанию и просто вызывают другие функции этого же интерфейса

interface Container {

   val childCount: Int

   // ❌ Не имеет смысла как функция интерфейса
   fun isEmpty(): Boolean = childCount == 0
}

// ✅ Дополнительное расширение, которое не нужно как часть API интерфейса
fun Container.isEmpty(): Boolean = childCount == 0

💬 Делитесь в комментариях используете ли вы такой подход при проектирование API

#kotlin