С какими работал паттернами проектирования

Работа с паттернами проектирования

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

Порождающие паттерны

Эти паттерны используются для создания объектов, предоставляя гибкие и инкапсулированные механизмы инстанцирования.

• Singleton — один из самых часто применяемых, но требующих осторожности паттернов. Использовал его для создания глобально доступных менеджеров, таких как ApiClient, SessionManager или DatabaseHelper. Ключевой момент — обеспечение потокобезопасной инициализации, например, через by lazy в Kotlin или двойную проверку в Java.

  object SessionManager {
      private val sharedPrefs: SharedPreferences by lazy {
          App.context.getSharedPreferences("session", Context.MODE_PRIVATE)
      }
  
      var authToken: String?
          get() = sharedPrefs.getString("auth_token", null)
          set(value) = sharedPrefs.edit().putString("auth_token", value).apply()
  }
  

• Builder — активно применял для конструирования сложных объектов, таких как запросы к сети (Retrofit.Builder), диалоги (AlertDialog.Builder) или настройки NotificationCompat.Builder. Это делает код создания более читаемым и защищает от ошибок с большим количеством параметров.

• Factory Method и Abstract Factory — использовал для создания семейств связанных зависимостей, особенно в случаях, когда логика инстанцирования должна быть отделена от основной бизнес-логики (например, создание разных репозиториев для работы с локальной базой и облачным API).

• Dependency Injection (DI) — хотя это и больше архитектурный подход, он часто реализуется через порождающие паттерны. Я применял как ручную инъекцию зависимостей, так и библиотеки (Dagger 2 и Hilt). DI является краеугольным камнем современной Android.

• Repository — ключевой паттерн из рекомендаций Google, который я использую повсеместно. Он абстрагирует источник данных (база данных, сеть, кэш) и предоставляет единый чистый API для доменного слоя.

Структурные паттерны

Эти паттерны помогают организовать классы и объекты в более крупные, гибкие структуры.

• Adapter — повседневный паттерн в Android. Помимо стандартных RecyclerView.Adapter, использовал его для адаптации интерфейсов сторонних библиотек под внутренние контракты приложения или для преобразования моделей API в доменные модели.
• Decorator — применял для динамического добавления новой функциональности объектам. Классический пример — обёртка InputStream в BufferedInputStream для добавления буферизации.
• Facade — создавал упрощённые интерфейсы для сложных подсистем. Например, ImageLoaderFacade, который внутри мог использовать Glide или Coil, но предоставлял разработчику простые методы load(url) и clearCache(), скрывая внутреннюю сложность.
• Composite — использовал при работе с древовидными структурами UI, например, при кастомной реализации сложных ViewGroup.

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

Эти паттерны отвечают за эффективную коммуникацию и распределение ответственности между объектами.

• Observer — фундаментальный паттерн для реактивного программирования в Android. Активно использовал его реализацию через RxJava и теперь через Kotlin Flow и LiveData. LiveData, по сути, является реализацией этого паттерна с учетом жизненного цикла.

• Strategy — применял для инкапсуляции алгоритмов, которые могут меняться. Например, разные стратегии кэширования (LRUCacheStrategy, DiskCacheStrategy) или стратегии сортировки списка в UI.

• Command — использовал для инкапсуляции запросов как объектов, что полезно для реализации истории действий (undo/redo), отложенного выполнения или организации очереди задач.

• MVVM (Model-View-ViewModel) — это архитектурный паттерн, сочетающий в себе несколько поведенческих. Является моим основным выбором при построении UI-слоя в соответствии с рекомендациями Google. ViewModel выступает в роли посредника между View (Activity/Fragment) и Model (бизнес-логика, данные), обеспечивая отделение логики от UI и выживаемость данных при изменениях конфигурации.

  // Пример использования ViewModel с LiveData
  class UserViewModel(private val repository: UserRepository) : ViewModel() {
      private val _userState = MutableLiveData<Result<User>>()
      val userState: LiveData<Result<User>> = _userState
  
      fun loadUser(userId: String) {
          viewModelScope.launch {
              _userState.value = Result.Loading
              _userState.value = repository.getUser(userId) // Репозиторий здесь — это стратегия получения данных
          }
      }
  }
  

Критерии выбора и эволюция подхода

Мой подход к использованию паттернов эволюционировал. Раньше я мог применять паттерн ради самого паттерна. Сейчас выбор всегда обоснован:

1. Решает ли паттерн конкретную проблему? (сложность создания, жесткая связность, невозможность тестирования).
2. Не добавляет ли он излишней абстракции? Паттерн должен упрощать, а не усложнять код.
3. Соответствует ли он принятой архитектуре? В современном Android с Clean Architecture и MVVM одни паттерны (Repository, DI) становятся обязательными, а другие (например, обширное использование Singleton) — антипаттернами, если нарушают инверсию зависимостей.

Таким образом, работа с паттернами — это не просто знание их списка, а умение выбирать правильный инструмент для задачи, часто комбинируя их (например, DI для внедрения Repository в ViewModel, который использует Observer для обновления View) в рамках чёткой архитектурной концепции.