🏝💉 Стал доступен плагин для проверки Koin из IDE

Проблема с валидацией DI графа зависимостей при использования Koin - очень актуальная. Авторы решили подойти к её решению через анализ кода проектов в IDE, хотя уже обсуждали перенос инструмента в CLI.

Для использования вам понадобится зарегистрироваться на сайте Kotzilla.

#kotlin #idea #koin

Metro — Kotlin DI фреймворк, вдохновленный Dagger, Anvil и Kotlin-Inject. Принципиальное отличие — работает через плагин компилятора, а не KSP. Пока нет релизов, всё в разработке.

Мне его только что прислали. Буду разбираться и пробовать, расскажу о нём на 🪙 Boosty

#kotlin #kmp #di

💉 Koin Annotations 2.0 Stable

Koin Annotations — надстройка над Koin для описания зависимостей с помощью аннотаций и последующей генерации части графа для них.

Что нового в движке:
👉 Совместимость с KSP2
👉 Улучшена работа компилятора DI кода
👉 Улучшена генерация кода
👉 Полноценная поддержка KMP проектов
👉 Шаринг описаний зависимостей между модулями проектов
👉 Работает с Koin 4.0, Kotlin 2.0.21 и KSP 2.0.21-1.0.28

Новые фичи для разработчиков:
👉 Создание собственных аннотаций квалификаторов
👉 Автоматические биндинги
👉 ComponentScan работает сквозь Gradle модули
👉 Аннотации над ViewModel (работает с Jetpack и KMP)

@KoinViewModel
class MyViewModel(deps: Deps): ViewModel()

Ссылка без VPN

#kotlin #kmp #di #koin

🏝 Автоматизация проверки архитектурной правильности вашего кода

Для Kotlin есть классный инструмент - Konsist, который позволяет писать тесты по структуре кода в проекте. Например, можно проверить, что все UseCase находятся в нужном пакете:

class UseCaseKonsistTest {
    @Test
    fun `every use case resides in use case package`() {
        Konsist
            // Задаем скоуп всего проекта
            .scopeFromProject()
            // Получаем все классы
            .classes()
            // Фильтруем классы
            .withNameEndingWith("UseCase")
            // Проверяем, что они находятся в нужном пакете
            .assertTrue { it.resideInPackage("..domain.usecase..") }
    }
}

Можно писать более сложные проверки для классов, интерфейсов, функций, свойств, Generic типов и многого другого. Надо будет использовать его для моего FrameIO.

Использовали его? Делитесь впечатлениями!
Еще не применяли? Пишите, чем может быть полезным для вашего проекта или, наоборот - нет смысла в утилите

#kotlin #архитектура

🏝 Как делать минималистичный 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

🏝 Обновили Kotlin Roadmap (февраль 2025)

Ключевые приоритеты разработки:
👉 Развитие возможностей языка: более высокие абстракции, лучшая производительность, более чистый код, повышение эффективности обработки данных.
👉 Kotlin Multiplatform: релиз "Kotlin to Swift Export", упрощение настройки проектов и создание KMP библиотек.
👉 Улучшение опыта сторонних контрибьюторов в экосистеме Kotlin.

#kotlin

🏝 Приоритеты развития Kotlin Compiler:

🆕 Финализация поддержки JSpecify (подробности здесь)
🆕 Завершение поддержки компилятора K1. Переносится в категорию "Deprecated"
🆕 Перевод Kotlin/Wasm (wasm-js) в Beta

Kotlin/Wasm:
⛏️ Переключение таргета wasm-wasi в библиотеках на WASI Preview 2
⛏️ Поддержка компонентной модели

#kotlin #wasm #k1