Facade: bazele patternului fațadă în arhitectura mobilă

Ce este patternul Facade?

Facade — pattern structural care oferă o interfață unificată către un grup de interfețe ale subsistemului. Definește o interfață de nivel înalt care simplifică utilizarea subsistemului. Facade nu adaugă funcționalitate nouă — orchesterază componentele existente, ascunzând de client complexitatea interacțiunii lor.

// Subsistem complex
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 — interfață simplă pentru 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 care ascunde AuthApi, UserDao și AnalyticsTracker de ViewModel. UI apelează loginUser(email, password) în loc de trei cereri separate către API, baza de date și analitică. Acest lucru reduce cuplajul: dacă mâine AuthApi devine FirebaseAuth sau UserDao migrează la Room, se schimbă doar Facade, nu și UI.

Facade în arhitectura mobilă: Service Layer

Service Layer — o implementare răspândită a Facade în aplicațiile mobile. Încapsulează logica de business și coordonarea între straturi. În Android, Service Layer este adesea implementat prin UseCase (Clean Architecture), în iOS — prin Manager sau protocoale Service.

AuthService unește toate cele patru componente. ViewModel apelează o singură metodă, fără să știe că sub capotă au loc o cerere de rețea, o scriere în baza de date, un tracking și o verificare a rețelei. La testare, AuthService poate fi înlocuit cu un mock, verificând toată logica de autentificare fără integrare cu componentele reale.

Facade vs Adapter vs Mediator

Facade, Adapter și Mediator — patternuri structurale, dar rezolvă probleme diferite. Sunt adesea confundate, deoarece toate trei introduc un obiect intermediar. Să analizăm diferențele pe exemplul unei aplicații mobile.

Facade nu ascunde subsistemul — clientul poate apela AuthApi direct, dacă este necesar. Adapter modifică obligatoriu interfața Adaptee. Mediator coordonează interacțiunile complexe dintre multe obiecte care s-ar putea să nu se cunoască între ele.

Implementarea Facade în Kotlin pentru Android

Implementarea Facade în Kotlin pentru Android cu Clean Architecture folosește UseCase ca punct de intrare pentru fiecare scenariu de business. UseCase este un Facade care ascunde repository, mapper-ul și alte dependențe de stratul UI.

// Repository — este tot Facade, dar cu un nivel mai jos
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 pentru scenariul de business
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 pentru scenariul de încărcare a profilului. Ascunde logica de cache (local → remote), maparea DTO → Entity → Profile și tracking-ul de analitică. ViewModel apelează invoke(userId) și primește un UserProfile gata sau o eroare. UseCase poate fi testat izolat, înlocuind repository cu un obiect mock.

Implementarea Facade în Swift pentru iOS

Facade în iOS este adesea implementat ca Manager sau Service. Spre deosebire de Android, iOS folosește protocoale pentru definirea interfeței Facade, ceea ce permite înlocuirea ușoară a implementărilor în teste. Să analizăm un Facade pentru lucrul cu media — încărcare, cache și afișare.

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. Verifică cache-ul
        if let cached = cache.image(for: url) {
            return .success(cached)
        }
        // 2. Încarcă datele
        let result = await downloader.download(from: url)
        guard case let .success(data) = result else {
            return .failure(MediaError.downloadFailed)
        }
        // 3. Decodează
        guard let image = decoder.decode(data) else {
            return .failure(MediaError.decodeFailed)
        }
        // 4. Salvează în cache
        cache.setImage(image, for: url)
        return .success(image)
    }
}

MediaService încapsulează un proces în trei pași: cache → încărcare → decodare. UI apelează o singură metodă loadImage(from:) în loc să gestioneze ImageCache, URLSession și ImageDecoder. La testare se poate înlocui MediaServiceProtocol cu un mock care returnează imagini prestabilite fără încărcare reală.

Greșeli tipice la utilizarea Facade

Greșelile la proiectarea Facade anulează avantajele lui: în loc de simplificare apare un God Object de care depinde tot sistemul. Să analizăm trei probleme principale.

God Facade — prea multă responsabilitate

Când un singur Facade conține metode pentru autentificare, încărcarea profilului, trimiterea mesajelor și sincronizare — acesta este un God Object. Semn: 15+ metode publice într-o singură clasă. Soluție: împărțirea în mai multe Facade specializate pe domenii de responsabilitate — AuthService, ProfileService, MessagingService.

Facade cu scurgerea detaliilor subsistemului

Dacă Facade returnează tipuri specifice subsistemului (de exemplu, FirebaseUser sau RealmObject), clientul rămâne totuși legat de o implementare concretă. Soluție: Facade trebuie să returneze doar tipuri proprii (data class / struct), abstractizând complet clientul de detaliile subsistemului.

Facade ca singurul punct de intrare

Când Facade interzice accesul direct la subsistem, devine un blocaj. Uneori clientul are nevoie de o metodă specifică a subsistemului, iar forțarea lui să treacă prin Facade este redundantă. Facade nu trebuie să fie un gatekeeper strict: oferă o interfață comodă, dar nu blochează accesul direct la componente.