Facade: základy vzoru fasáda v mobilní architektuře

Co je vzor Facade?

Facade — strukturální vzor, který poskytuje jednotné rozhraní ke skupině rozhraní subsystému. Definuje rozhraní na vysoké úrovni, které zjednodušuje použití subsystému. Facade nepřidává novou funkcionalitu — orchestruje stávající komponenty a skrývá složitost jejich vzájemné interakce před klientem.

// Složitý subsystém
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 — jednoduché rozhraní pro 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, který skrývá AuthApi, UserDao a AnalyticsTracker před ViewModel. UI volá loginUser(email, password) místo tří samostatných požadavků na API, databázi a analytiku. To snižuje provázanost: pokud se zítra AuthApi stane FirebaseAuth nebo UserDao migruje na Room, změní se pouze Facade, ne UI.

Facade v mobilní architektuře: Service Layer

Service Layer — rozšířená implementace vzoru Facade v mobilních aplikacích. Zapouzdřuje obchodní logiku a koordinaci mezi vrstvami. V systému Android se Service Layer často implementuje přes UseCase (Clean Architecture), v systému iOS — přes Manager nebo protokoly Service.

AuthService spojuje všechny čtyři komponenty. ViewModel volá jednu metodu, aniž by věděl, že pod kapotou probíhá síťový požadavek, zápis do databáze, sledování a kontrola sítě. Při testování lze AuthService nahradit mockem a ověřit celou logiku autentizace bez integrace se skutečnými komponentami.

Facade vs Adapter vs Mediator

Facade, Adapter a Mediator — strukturální vzory, ale řeší různé úkoly. Často se zaměňují, protože všechny tři zavádějí zprostředkující objekt. Rozebereme rozdíly na příkladu mobilní aplikace.

Facade neskrývá subsystém — klient může v případě potřeby přistupovat přímo k AuthApi. Adapter povinně mění rozhraní Adaptee. Mediator koordinuje složité interakce mezi mnoha objekty, které se navzájem nemusí znát.

Implementace vzoru Facade v Kotlin pro Android

Implementace vzoru Facade v Kotlin pro Android s Clean Architecture používá UseCase jako vstupní bod pro každý obchodní scénář. UseCase je Facade, který skrývá repozitář, mapper a další závislosti před vrstvou UI.

// Repository — také Facade, ale o úroveň níže
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 pro obchodní scénář
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 pro scénář načítání profilu. Skrývá logiku cachování (local → remote), mapování DTO → Entity → Profile a sledování analytiky. ViewModel volá invoke(userId) a dostává hotový UserProfile nebo chybu. UseCase lze testovat izolovaně, když repozitář nahradíme mock objektem.

Implementace vzoru Facade ve Swift pro iOS

Facade v systému iOS se často implementuje jako Manager nebo Service. Na rozdíl od systému Android používá iOS protokoly pro definování rozhraní vzoru Facade, což umožňuje snadno nahrazovat implementace v testech. Probereme Facade pro práci s médii — načítání, cachování a zobrazování.

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. Zkontrolovat cache
        if let cached = cache.image(for: url) {
            return .success(cached)
        }
        // 2. Načíst data
        let result = await downloader.download(from: url)
        guard case let .success(data) = result else {
            return .failure(MediaError.downloadFailed)
        }
        // 3. Dekódovat
        guard let image = decoder.decode(data) else {
            return .failure(MediaError.decodeFailed)
        }
        // 4. Uložit do cache
        cache.setImage(image, for: url)
        return .success(image)
    }
}

MediaService zapouzdřuje tříkrokový proces: cache → načtení → dekódování. UI volá jednu metodu loadImage(from:) místo správy ImageCache, URLSession a ImageDecoder. Při testování lze MediaServiceProtocol nahradit mockem, který vrací přednastavené obrázky bez skutečného načítání.

Typické chyby při použití vzoru Facade

Chyby při návrhu vzoru Facade ničí jeho výhody: místo zjednodušení vzniká God Object, na kterém závisí celý systém. Probereme tři hlavní problémy.

God Facade — příliš mnoho odpovědnosti

Když jeden Facade obsahuje metody pro autentizaci, načítání profilu, odesílání zpráv a synchronizaci — to je God Object. Znak: více než 15 veřejných metod v jedné třídě. Řešení: rozdělit na několik specializovaných vzorů Facade podle oblastí odpovědnosti — AuthService, ProfileService, MessagingService.

Facade s únikem detailů subsystému

Pokud Facade vrací typy specifické pro subsystém (například FirebaseUser nebo RealmObject), klient je stále vázán na konkrétní implementaci. Řešení: Facade by měl vracet pouze vlastní typy (data class / struct), čímž klienta zcela abstrahuje od detailů subsystému.

Facade jako jediný vstupní bod

Když Facade zakazuje přímý přístup k subsystému, stává se úzkým hrdlem. Někdy klient potřebuje specifickou metodu subsystému a nutit ho procházet přes Facade je zbytečné. Facade by neměl být přísný gatekeeper: poskytuje pohodlné rozhraní, ale neblokuje přímý přístup ke komponentám.