Какие использовал паттерны проектирования

Использованные паттерны проектирования в Android-разработке

В моей практике разработки Android-приложений я активно применяю паттерны проектирования для создания масштабируемой, поддерживаемой и тестируемой архитектуры. Паттерны помогают решать типовые проблемы проектирования и разделять ответственность между компонентами.

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

1. Model View ViewModel (MVVM)

Наиболее распространённый архитектурный паттерн в современных Android-приложениях:

• Model — отвечает за данные и бизнес-логику (репозитории, Use Cases)
• ViewModel — хранит состояние UI и обрабатывает логику представления, обеспечивая жизнестойкость данных при поворотах экрана
• View (Activity/Fragment) — отвечает только за отображение и пользовательский ввод

class UserViewModel(private val repository: UserRepository) : ViewModel() {
    private val _users = MutableLiveData<List<User>>()
    val users: LiveData<List<User>> = _users
    
    fun loadUsers() {
        viewModelScope.launch {
            _users.value = repository.getUsers()
        }
    }
}

2. Repository Pattern

Ключевой паттерн для абстрагирования источника данных:

• Единый интерфейс для доступа к данным независимо от их источника (сеть, БД, кэш)
• Реализует стратегию кэширования
• Упрощает тестирование и замену источников данных

interface UserRepository {
    suspend fun getUsers(): List<User>
    suspend fun getUserById(id: String): User
}

class UserRepositoryImpl(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) : UserRepository {
    override suspend fun getUsers(): List<User> {
        return try {
            val remoteUsers = remoteDataSource.getUsers()
            localDataSource.saveUsers(remoteUsers)
            remoteUsers
        } catch (e: Exception) {
            localDataSource.getUsers()
        }
    }
}

Паттерны создания объектов

3. Dependency Injection (DI)

Чаще всего реализую через Hilt или Koin:

• Уменьшает связность компонентов
• Упрощает тестирование (замены зависимостей на моки)
• Управляет жизненным циклом зависимостей

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {
    @Provides
    @Singleton
    fun provideRetrofit(): Retrofit {
        return Retrofit.Builder()
            .baseUrl("https://api.example.com/")
            .addConverterFactory(GsonConverterFactory.create())
            .build()
    }
}

4. Singleton

Для управления уникальными ресурсами:

• Retrofit клиенты
• Базы данных Room
• Менеджеры навигации, сессий

object AnalyticsTracker {
    private val events = mutableListOf<AnalyticsEvent>()
    
    fun trackEvent(event: AnalyticsEvent) {
        events.add(event)
        // Отправка на сервер
    }
}

Поведенческие паттерны

5. Observer

Повсеместно используется в Android через:

• LiveData — наблюдение за изменениями данных с учётом жизненного цикла
• Flow — асинхронные потоки данных в корутинах
• Callback интерфейсы

class ProductViewModel : ViewModel() {
    private val _products = MutableStateFlow<List<Product>>(emptyList())
    val products: StateFlow<List<Product>> = _products.asStateFlow()
    
    fun observeProducts() {
        viewModelScope.launch {
            repository.getProductsFlow().collect { products ->
                _products.value = products
            }
        }
    }
}

6. Builder

Для создания сложных объектов:

• AlertDialog в Android
• Retrofit.Builder, OkHttpClient.Builder
• Кастомные конфигурационные объекты

class NotificationBuilder {
    private var title: String = ""
    private var message: String = ""
    private var icon: Int = 0
    
    fun setTitle(title: String): NotificationBuilder {
        this.title = title
        return this
    }
    
    fun build(): Notification {
        return Notification(title, message, icon)
    }
}

Другие часто используемые паттерны

• Adapter — для RecyclerView, преобразования данных
• Factory — создание объектов в зависимости от условий
• Strategy — различные алгоритмы обработки данных
• Decorator — расширение функциональности классов

Критерии выбора паттернов

В своей работе я выбираю паттерны исходя из:

1. Сложности компонента и его жизненного цикла
2. Тестируемости — паттерны должны позволять легко писать unit-тесты
3. Связности — стремлюсь к низкой связности между модулями
4. Соответствия Android-специфике (учёт жизненных циклов, конфигурационных изменений)

Наиболее важным считаю комбинацию паттернов — например, MVVM с Repository, DI и Observer, что создает robust-архитектуру, устойчивую к изменениям требований и масштабированию приложения. Паттерны не являются догмой, но их осмысленное применение значительно повышает качество кода.