С какими структурами работал помимо Data class

Конечно, помимо Data class, я активно работал с широким спектром структур данных и классов в Kotlin/Java, выбирая их в зависимости от требований задачи: для моделирования состояний, инкапсуляции логики, организации коллекций или достижения специфических целей в архитектуре приложения.

Основные классы и структуры

1. Sealed Class (Sealed Interface)

Идеальны для представления ограниченной иерархии типов, часто используются для моделирования состояний UI или результатов операций.

sealed class Result<out T> {
    data class Success<T>(val data: T) : Result<T>()
    data class Error(val exception: Throwable) : Result<Nothing>()
    object Loading : Result<Nothing>()
}

// Использование в ViewModel
private fun loadData() {
    _state.value = Result.Loading
    try {
        val data = repository.fetchData()
        _state.value = Result.Success(data)
    } catch (e: Exception) {
        _state.value = Result.Error(e)
    }
}

Преимущества: Исчерпывающая проверка в when выражениях (если не добавить else, компилятор предупредит о неполном покрытии), что повышает безопасность и читаемость кода.

2. Enum Class

Используются, когда нужно определить фиксированный набор константных значений, часто для статусов, типов, флагов.

enum class ViewType(val layoutId: Int) {
    TEXT(R.layout.item_text),
    IMAGE(R.layout.item_image),
    VIDEO(R.layout.item_video);

    companion object {
        fun fromLayoutId(id: Int): ViewType? = values().find { it.layoutId == id }
    }
}

Ключевое отличие от Sealed Class: Экземпляры Enum существуют в единственном экземпляре (синглтоны), не могут нести различные данные в каждом случае (хотя могут иметь свойства). Sealed Class лучше подходит для иерархий, где каждый подтип может иметь уникальную структуру данных.

3. Parcelable и его современные альтернативы

Для эффективной передачи данных между компонентами Android (через Intent, Bundle, SavedStateHandle).

• Parcelable (Java/Kotlin): Ручная реализация для максимальной производительности.

  @Parcelize // Аннотация из kotlin-parcelize делает реализацию автоматической
  data class User(val id: Long, val name: String) : Parcelable
  

• Serializable (Java): Более простой, но менее производительный интерфейс.
• Классы с @TypeConverter для Room: Для хранения сложных объектов в базе данных.

  class Converters {
      @TypeConverter
      fun fromTimestamp(value: Long?): Date? = value?.let { Date(it) }
  
      @TypeConverter
      fun dateToTimestamp(date: Date?): Long? = date?.time
  }
  

4. Обычные классы (Regular Class)

Использую для объектов, которые несут поведение (логику) или имеют изменяемое состояние.

• Служебные классы (Utils): Хотя предпочитаю функции-расширения (extension functions), иногда классы с object или @JvmStatic методами нужны для взаимодействия с Java или группировки.
• Модели с валидацией и бизнес-логикой:

  class ShoppingCart {
      private val items = mutableListOf<CartItem>()
  
      fun addItem(item: CartItem) {
          require(item.quantity > 0) { "Quantity must be positive" }
          // Сложная логика проверки и добавления
          items.add(item)
          recalculateTotal()
      }
  
      private fun recalculateTotal() { /* ... */ }
  }
  

5. Коллекции из стандартной библиотеки Kotlin (Collections)

Работа с коллекциями — это ежедневная практика. Выбор структуры критичен для производительности:

• Списки (List, MutableList): ArrayList — стандарт для индексированного доступа.
• Множества (Set, MutableSet): HashSet для уникальности и быстрого поиска, LinkedHashSet для сохранения порядка добавления.
• Ассоциативные массивы (Map, MutableMap): HashMap для быстрого доступа по ключу, LinkedHashMap для порядка.
• Специализированные коллекции: ArrayDeque для эффективных операций "первым вошел, первым вышел" (FIFO) или "последним вошел, первым вышел" (LIFO).

6. Специальные классы для реактивного потоков и асинхронности

• Flow<T> (Cold Stream): Для потоков данных в корутинах. Часто оборачиваю результаты запросов к БД или сетевых вызовов в Flow или StateFlow.
• StateFlow и SharedFlow: StateFlow — для хранения и наблюдения за состоянием UI (аналог LiveData, но в корутинном мире). SharedFlow — для событий (например, навигационных команд или одноразовых сообщений).

  class MyViewModel : ViewModel() {
      private val _uiState = MutableStateFlow<UiState>(UiState.Loading)
      val uiState: StateFlow<UiState> = _uiState.asStateFlow()
  
      private val _navigationEvent = MutableSharedFlow<NavigationCommand>()
      val navigationEvent: SharedFlow<NavigationCommand> = _navigationEvent.asSharedFlow()
  }
  

Критерии выбора структуры

1. Неизменяемость (Immutability): Предпочитаю data class с val свойствами для моделей. Для изменяемых состояний использую MutableStateFlow или MutableLiveData внутри ViewModel, скрывая мутабельный интерфейс.
2. Назначение данных:

    *   **Модели ответа API / сущности БД:** `data class` (часто с аннотациями Moshi, Gson или Room).
    *   **Состояние View / Результат операции:** `sealed class` (или `sealed interface` в современных проектах).
    *   **Конфигурация, флаги:** `enum class`.
    *   **Объект с поведением и состоянием:** обычный `class`.

1. Производительность: Для межпроцессного взаимодействия или сериализации больших объектов выбираю Parcelable (с @Parcelize) вместо Serializable. Для частых операций поиска — Set или Map.
2. Совместимость с библиотеками: Например, Room требует @Entity для таблиц, @TypeConverter для сложных типов. Retrofit часто использует data class для моделирования JSON.

Таким образом, выбор структуры — это всегда баланс между читаемостью, безопасностью типов, производительностью и требованиями конкретных компонентов Android-экосистемы (Activity, Fragment, ViewModel, Room, Retrofit). Data class — отличный инструмент, но лишь один из многих в арсенале разработчика.