Facade: основы паттерна фасад в мобильной архитектуре

Что такое паттерн Facade?

Facade — структурный паттерн, который предоставляет унифицированный интерфейс к группе интерфейсов подсистемы. Он определяет высокоуровневый интерфейс, упрощающий использование подсистемы. Facade не добавляет новой функциональности — он оркестрирует существующие компоненты, скрывая сложность их взаимодействия от клиента.

// Сложная подсистема
class AuthApi {
    suspend fun login(email: String, pass: String): TokenResponse
}

class UserDao {
    suspend fun saveUser(user: UserEntity)
    suspend fun getUser(id: Long): UserEntity?
}

class AnalyticsTracker {
    fun track(event: String, params: Map)
}

// Facade — простой интерфейс для UI
class AuthService(
    private val api: AuthApi,
    private val dao: UserDao,
    private val analytics: AnalyticsTracker
) {
    suspend fun loginUser(email: String, password: String): Result {
        return runCatching {
            val token = api.login(email, password)
            val user = User(token.userId, email, token.accessToken)
            dao.saveUser(user.toEntity())
            analytics.track("login_success", mapOf("method" to "email"))
            user
        }
    }
}

AuthService — Facade, скрывающий AuthApi, UserDao и AnalyticsTracker от ViewModel. UI вызывает loginUser(email, password) вместо трёх отдельных запросов к API, БД и аналитике. Это снижает связанность: если завтра AuthApi станет FirebaseAuth или UserDao мигрирует на Room, изменится только Facade, а не UI.

Facade в мобильной архитектуре: Service Layer

Service Layer — распространённая реализация Facade в мобильных приложениях. Он инкапсулирует бизнес-логику и координацию между слоями. В Android Service Layer часто реализуется через UseCase (Clean Architecture), в iOS — через Manager или Service протоколы.

AuthService объединяет все четыре компонента. ViewModel вызывает один метод, не зная, что под капотом происходит сетевой запрос, запись в БД, трекинг и проверка сети. При тестировании AuthService можно заменить mock'ом, проверив всю логику авторизации без интеграции с реальными компонентами.

Facade vs Adapter vs Mediator

Facade, Adapter и Mediator — структурные паттерны, но решают разные задачи. Их часто путают, так как все три вводят объект-посредник. Разберём различия на примере мобильного приложения.

Facade не скрывает подсистему — клиент может при необходимости обратиться к AuthApi напрямую. Adapter в обязательном порядке меняет интерфейс Adaptee. Mediator координирует сложные взаимодействия между множеством объектов, которые могут не знать друг о друге.

Реализация Facade на Kotlin для Android

Реализация Facade на Kotlin для Android с Clean Architecture использует UseCase как точку входа для каждого бизнес-сценария. UseCase — это Facade, скрывающий репозиторий, маппер и другие зависимости от UI-слоя.

// Repository — тоже Facade, но уровень ниже
class UserRepositoryImpl(
    private val local: UserLocalDataSource,
    private val remote: UserRemoteDataSource,
    private val mapper: UserMapper
) : UserRepository {
    override suspend fun getUserProfile(id: String): UserProfile {
        val cached = local.getUser(id)
        if (cached != null && !cached.isStale) {
            return mapper.toProfile(cached)
        }
        val dto = remote.fetchUser(id)
        val entity = mapper.toEntity(dto)
        local.saveUser(entity)
        return mapper.toProfile(entity)
    }
}

// UseCase — Facade для бизнес-сценария
class LoadUserProfileUseCase(
    private val repo: UserRepository,
    private val analytics: AnalyticsTracker
) {
    suspend operator fun invoke(userId: String): Result {
        return runCatching {
            val profile = repo.getUserProfile(userId)
            analytics.track("profile_loaded", mapOf("user_id" to userId))
            profile
        }
    }
}

LoadUserProfileUseCase — Facade для сценария загрузки профиля. Он скрывает логику кэширования (local → remote), маппинг DTO → Entity → Profile и трекинг аналитики. ViewModel вызывает invoke(userId) и получает готовый UserProfile или ошибку. UseCase можно тестировать изолированно, заменяя репозиторий mock-объектом.

Реализация Facade на Swift для iOS

Facade в iOS часто реализуется как Manager или Service. В отличие от Android, iOS использует протоколы для определения интерфейса Facade, что позволяет легко подменять реализации в тестах. Рассмотрим Facade для работы с медиа — загрузка, кэширование и отображение.

protocol MediaServiceProtocol {
    func loadImage(from url: URL) async -> Result<UIImage, Error>
}

final class MediaService: MediaServiceProtocol {
    private let cache: ImageCache
    private let downloader: ImageDownloader
    private let decoder: ImageDecoder
    
    func loadImage(from url: URL) async -> Result<UIImage, Error> {
        // 1. Проверить кэш
        if let cached = cache.image(for: url) {
            return .success(cached)
        }
        // 2. Загрузить данные
        let result = await downloader.download(from: url)
        guard case let .success(data) = result else {
            return .failure(MediaError.downloadFailed)
        }
        // 3. Декодировать
        guard let image = decoder.decode(data) else {
            return .failure(MediaError.decodeFailed)
        }
        // 4. Сохранить в кэш
        cache.setImage(image, for: url)
        return .success(image)
    }
}

MediaService инкапсулирует трёхшаговый процесс: кэш → загрузка → декодирование. UI вызывает один метод loadImage(from:) вместо управления ImageCache, URLSession и ImageDecoder. При тестировании можно подменить MediaServiceProtocol mock'ом, возвращающим предустановленные изображения без реальной загрузки.

Типичные ошибки при использовании Facade

Ошибки при проектировании Facade сводят на нет его преимущества: вместо упрощения получается God Object, от которого зависит вся система. Разберём три главные проблемы.

God Facade — слишком много ответственности

Когда один Facade содержит методы для авторизации, загрузки профиля, отправки сообщений и синхронизации — это God Object. Признак: 15+ публичных методов в одном классе. Решение: разделить на несколько специализированных Facade по областям ответственности — AuthService, ProfileService, MessagingService.

Facade с утечкой деталей подсистемы

Если Facade возвращает типы, специфичные для подсистемы (например, FirebaseUser или RealmObject), клиент всё равно привязан к конкретной реализации. Решение: Facade должен возвращать только собственные типы (data class / struct), полностью абстрагируя клиента от деталей подсистемы.

Facade как единственная точка входа

Когда Facade запрещает прямой доступ к подсистеме, он становится bottleneck. Иногда клиенту нужен специфический метод подсистемы, и заставлять его проходить через Facade — избыточно. Facade не должен быть строгим gatekeeper: он предоставляет удобный интерфейс, но не блокирует прямой доступ к компонентам.