Facade: fundamentos do padrão fachada na arquitetura móvel

O que é o padrão Facade?

Facade é um padrão estrutural que fornece uma interface unificada para um grupo de interfaces do subsistema. Ele define uma interface de alto nível que simplifica o uso do subsistema. O Facade não adiciona nova funcionalidade — ele orquestra os componentes existentes, ocultando a complexidade da sua interação do cliente.

// Subsistema complexo
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 — uma interface simples para a 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 é um Facade que oculta AuthApi, UserDao e AnalyticsTracker do ViewModel. A UI chama loginUser(email, password) em vez de três requisições separadas à API, ao banco de dados e à análise. Isso reduz o acoplamento: se amanhã AuthApi virar FirebaseAuth ou UserDao migrar para Room, apenas o Facade muda, não a UI.

Facade na arquitetura móvel: Service Layer

Service Layer é uma implementação comum do Facade em aplicativos móveis. Ele encapsula a lógica de negócio e a coordenação entre camadas. No Android, o Service Layer é frequentemente implementado via UseCase (Clean Architecture), e no iOS via protocolos Manager ou Service.

AuthService combina todos os quatro componentes. O ViewModel chama um único método sem saber que, por baixo dos panos, acontecem requisição de rede, escrita no banco, rastreamento e verificação de rede. Ao testar, o AuthService pode ser substituído por um mock, verificando toda a lógica de autenticação sem integração com componentes reais.

Facade vs Adapter vs Mediator

Facade, Adapter e Mediator são padrões estruturais, mas resolvem problemas diferentes. Eles são frequentemente confundidos, pois os três introduzem um objeto intermediário. Vamos analisar as diferenças usando um aplicativo móvel como exemplo.

Facade não oculta o subsistema — o cliente pode acessar o AuthApi diretamente quando necessário. Adapter obrigatoriamente muda a interface do Adaptee. Mediator coordena interações complexas entre muitos objetos que podem não se conhecer.

Implementação do Facade em Kotlin para Android

A implementação do Facade em Kotlin para Android com Clean Architecture usa UseCase como ponto de entrada para cada cenário de negócio. UseCase é um Facade que oculta o repositório, o mapper e outras dependências da camada de UI.

// Repository também é um Facade, mas em nível inferior
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 — um Facade para o cenário de negócio
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 é um Facade para o cenário de carregamento de perfil. Ele oculta a lógica de cache (local → remoto), o mapeamento DTO → Entity → Profile e o rastreamento de análise. O ViewModel chama invoke(userId) e recebe um UserProfile pronto ou um erro. O UseCase pode ser testado isoladamente, substituindo o repositório por um objeto mock.

Implementação do Facade em Swift para iOS

Facade no iOS é frequentemente implementado como Manager ou Service. Ao contrário do Android, o iOS usa protocolos para definir a interface do Facade, o que permite trocar facilmente as implementações nos testes. Vamos ver um Facade para trabalhar com mídia — carregamento, cache e exibição.

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. Verificar o cache
        if let cached = cache.image(for: url) {
            return .success(cached)
        }
        // 2. Carregar os dados
        let result = await downloader.download(from: url)
        guard case let .success(data) = result else {
            return .failure(MediaError.downloadFailed)
        }
        // 3. Decodificar
        guard let image = decoder.decode(data) else {
            return .failure(MediaError.decodeFailed)
        }
        // 4. Salvar no cache
        cache.setImage(image, for: url)
        return .success(image)
    }
}

MediaService encapsula um processo de três etapas: cache → carregamento → decodificação. A UI chama um único método loadImage(from:) em vez de gerenciar ImageCache, URLSession e ImageDecoder. Ao testar, MediaServiceProtocol pode ser substituído por um mock que retorna imagens predefinidas sem carregamento real.

Erros típicos ao usar o Facade

Os erros no projeto do Facade anulam suas vantagens: em vez de simplificação, você obtém um God Object do qual todo o sistema depende. Vamos analisar os três principais problemas.

God Facade — responsabilidade demais

Quando um único Facade contém métodos para autenticação, carregamento de perfil, envio de mensagens e sincronização — isso é um God Object. Sinal: mais de 15 métodos públicos em uma classe. Solução: dividir em vários Facades especializados por áreas de responsabilidade — AuthService, ProfileService, MessagingService.

Facade com vazamento de detalhes do subsistema

Se o Facade retorna tipos específicos do subsistema (por exemplo, FirebaseUser ou RealmObject), o cliente ainda fica preso a uma implementação concreta. Solução: o Facade deve retornar apenas seus próprios tipos (data class / struct), abstraindo totalmente o cliente dos detalhes do subsistema.

Facade como único ponto de entrada

Quando o Facade proíbe o acesso direto ao subsistema, ele se torna um gargalo. Às vezes o cliente precisa de um método específico do subsistema, e forçá-lo a passar pelo Facade é redundante. Facade não deve ser um gatekeeper rígido: ele fornece uma interface conveniente, mas não bloqueia o acesso direto aos componentes.