Facade: a homlokzati minta alapjai a mobil architektúrában

Mi az a Facade minta?

Facade — strukturális minta, amely egységes interfészt biztosít az alrendszer interfészeinek csoportjához. Magas szintű interfészt határoz meg, amely egyszerűsíti az alrendszer használatát. A Facade nem ad hozzá új funkcionalitást — a meglévő komponenseket orkesztrálja, elrejtve azok interakciójának összetettségét az ügyfél elől.

// Összetett alrendszer
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 — egyszerű interfész a UI számára
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, amely az AuthApi-t, a UserDao-t és az AnalyticsTracker-t elrejti a ViewModel elől. A UI a loginUser(email, password) metódust hívja a három külön API-, adatbázis- és analitika-kérés helyett. Ez csökkenti a csatolást: ha holnap az AuthApi FirebaseAuth lesz, vagy a UserDao Room-ra migrál, csak a Facade változik, a UI nem.

Facade a mobil architektúrában: Service Layer

Service Layer — a Facade elterjedt megvalósítása a mobilalkalmazásokban. Beágyazza az üzleti logikát és a rétegek közötti koordinációt. Androidon a Service Layer gyakran UseCase-en (Clean Architecture), iOS-en pedig Manager vagy Service protokollokon keresztül valósul meg.

AuthService mind a négy komponenst egyesíti. A ViewModel egyetlen metódust hív, anélkül hogy tudná, hogy a motorháztető alatt hálózati kérés, adatbázisba írás, nyomkövetés és hálózatellenőrzés zajlik. Teszteléskor az AuthService mockkal helyettesíthető, és a teljes hitelesítési logika ellenőrizhető a valódi komponensekkel való integráció nélkül.

Facade vs Adapter vs Mediator

Facade, Adapter és Mediator — strukturális minták, de különböző feladatokat oldanak meg. Gyakran összekeverik őket, mivel mindhárom közvetítő objektumot vezet be. Vizsgáljuk meg a különbségeket egy mobilalkalmazás példáján.

Facade nem rejti el az alrendszert — az ügyfél szükség esetén közvetlenül hozzáférhet az AuthApi-hoz. Adapter kötelezően megváltoztatja az Adaptee interfészét. Mediator számos, egymást esetleg nem ismerő objektum közötti összetett interakciókat koordinál.

A Facade megvalósítása Kotlinban Androidhoz

A Facade megvalósítása Kotlinban Androidhoz a Clean Architecture-szel a UseCase-t használja belépési pontként minden üzleti forgatókönyvhöz. A UseCase egy Facade, amely a repositoryt, a mappert és más függőségeket elrejti a UI-réteg elől.

// Repository — szintén Facade, de egy szinttel lejjebb
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 az üzleti forgatókönyvhöz
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 a profilbetöltési forgatókönyvhöz. Elrejti a gyorsítótárazási logikát (local → remote), a DTO → Entity → Profile leképezést és az analitikai nyomkövetést. A ViewModel az invoke(userId) metódust hívja, és kész UserProfile-ot vagy hibát kap. A UseCase izoláltan tesztelhető, ha a repositoryt mock objektumra cseréljük.

A Facade megvalósítása Swiftben iOS-hez

Facade iOS-ben gyakran Manager vagy Service formájában valósul meg. Az Androiddal ellentétben az iOS protokollokat használ a Facade interfészének meghatározására, ami megkönnyíti a megvalósítások cseréjét a tesztekben. Vizsgáljuk meg a médiával való munkához készült Facade-et — betöltés, gyorsítótárazás és megjelenítés.

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. Gyorsítótár ellenőrzése
        if let cached = cache.image(for: url) {
            return .success(cached)
        }
        // 2. Adatok betöltése
        let result = await downloader.download(from: url)
        guard case let .success(data) = result else {
            return .failure(MediaError.downloadFailed)
        }
        // 3. Dekódolás
        guard let image = decoder.decode(data) else {
            return .failure(MediaError.decodeFailed)
        }
        // 4. Mentés a gyorsítótárba
        cache.setImage(image, for: url)
        return .success(image)
    }
}

MediaService egy háromlépéses folyamatot ágyaz be: gyorsítótár → betöltés → dekódolás. A UI egyetlen loadImage(from:) metódust hív az ImageCache, az URLSession és az ImageDecoder kezelése helyett. Teszteléskor a MediaServiceProtocol mockra cserélhető, amely valódi betöltés nélkül előre beállított képeket ad vissza.

Tipikus hibák a Facade használata során

A hibák a Facade tervezésekor semmissé teszik annak előnyeit: az egyszerűsítés helyett God Object jön létre, amelytől az egész rendszer függ. Vizsgáljuk meg a három fő problémát.

God Facade — túl sok felelősség

Amikor egy Facade hitelesítési, profilbetöltési, üzenetküldési és szinkronizálási metódusokat tartalmaz — ez egy God Object. Jele: 15+ nyilvános metódus egyetlen osztályban. Megoldás: osszuk szét több specializált Facade-re a felelősségi területek szerint — AuthService, ProfileService, MessagingService.

Az alrendszer részleteit kiszivárogtató Facade

Ha a Facade az alrendszerre jellemző típusokat ad vissza (például FirebaseUser vagy RealmObject), az ügyfél akkor is egy konkrét megvalósításhoz kötődik. Megoldás: a Facade-nek csak saját típusokat (data class / struct) szabad visszaadnia, teljesen elvonatkoztatva az ügyfelet az alrendszer részleteitől.

Facade mint egyetlen belépési pont

Amikor a Facade megtiltja a közvetlen hozzáférést az alrendszerhez, szűk keresztmetszetté válik. Néha az ügyfélnek az alrendszer egy speciális metódusára van szüksége, és arra kényszeríteni, hogy a Facade-en keresztül menjen, felesleges. A Facade ne legyen szigorú kapuőr: kényelmes interfészt biztosít, de nem blokkolja a közvetlen hozzáférést a komponensekhez.