Facade: mga batayan ng pattern ng facade sa mobile na arkitektura

Ano ang pattern ng Facade?

Facade — istruktural na pattern na nagbibigay ng pinag-isang interface sa isang grupo ng mga interface ng subsystem. Tinutukoy nito ang isang interface sa mataas na antas na nagpapasimple sa paggamit ng subsystem. Hindi nagdaragdag ng bagong functionality ang Facade — inoorkestra nito ang mga umiiral na component at itinatago ang pagiging kumplikado ng kanilang interaksyon mula sa kliyente.

// Kumplikadong subsystem
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 — simpleng interface para sa 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 na nagtatago ng AuthApi, UserDao, at AnalyticsTracker mula sa ViewModel. Tumatawag ang UI ng loginUser(email, password) sa halip na tatlong hiwalay na kahilingan sa API, database, at analytics. Binabawasan nito ang coupling: kung bukas ay magiging FirebaseAuth ang AuthApi o magmi-migrate ang UserDao sa Room, ang Facade lamang ang magbabago, hindi ang UI.

Facade sa mobile na arkitektura: Service Layer

Service Layer — karaniwang pagpapatupad ng Facade sa mga mobile application. Ine-encapsulate nito ang business logic at ang koordinasyon sa pagitan ng mga layer. Sa Android, ang Service Layer ay kadalasang ipinapatupad sa pamamagitan ng UseCase (Clean Architecture), sa iOS — sa pamamagitan ng Manager o mga Service protocol.

AuthService pinag-iisa ang lahat ng apat na component. Tumatawag ang ViewModel ng isang method, nang hindi nalalaman na sa ilalim ng hood ay nangyayari ang isang network request, pagsulat sa database, tracking, at pagsusuri ng network. Sa pag-test, maaaring palitan ang AuthService ng mock, na sinusuri ang buong lohika ng pagpapatotoo nang walang integrasyon sa mga totoong component.

Facade vs Adapter vs Mediator

Facade, Adapter, at Mediator — mga istruktural na pattern, ngunit nilulutas nila ang iba't ibang problema. Madalas silang napagkakamalan, dahil lahat ng tatlo ay nagpapakilala ng isang tagapamagitang object. Tingnan natin ang mga pagkakaiba gamit ang halimbawa ng isang mobile application.

Facade ay hindi itinatago ang subsystem — maaaring direktang ma-access ng kliyente ang AuthApi kung kinakailangan. Adapter ay sapilitang binabago ang interface ng Adaptee. Mediator ay kinoordina ang mga kumplikadong interaksyon sa pagitan ng maraming object na maaaring hindi kilala ang isa't isa.

Pagpapatupad ng Facade sa Kotlin para sa Android

Ang pagpapatupad ng Facade sa Kotlin para sa Android na may Clean Architecture ay gumagamit ng UseCase bilang entry point para sa bawat business scenario. Ang UseCase ay isang Facade na nagtatago ng repository, mapper, at iba pang dependencies mula sa UI layer.

// Repository — Facade din, ngunit isang antas na mas mababa
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 para sa business scenario
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 para sa scenario ng pag-load ng profile. Itinatago nito ang lohika ng caching (local → remote), ang pagmamapa ng DTO → Entity → Profile, at ang pagsubaybay ng analytics. Tumatawag ang ViewModel ng invoke(userId) at tumatanggap ng handa nang UserProfile o isang error. Maaaring i-test ang UseCase nang nakahiwalay sa pamamagitan ng pagpapalit ng repository ng mock object.

Pagpapatupad ng Facade sa Swift para sa iOS

Ang Facade sa iOS ay kadalasang ipinapatupad bilang Manager o Service. Hindi tulad ng Android, gumagamit ang iOS ng mga protocol upang tukuyin ang interface ng Facade, na ginagawang madali ang pagpapalit ng mga pagpapatupad sa mga test. Tingnan natin ang isang Facade para sa pagtatrabaho sa media — pag-load, pag-cache, at pagpapakita.

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. Suriin ang cache
        if let cached = cache.image(for: url) {
            return .success(cached)
        }
        // 2. I-load ang data
        let result = await downloader.download(from: url)
        guard case let .success(data) = result else {
            return .failure(MediaError.downloadFailed)
        }
        // 3. I-decode
        guard let image = decoder.decode(data) else {
            return .failure(MediaError.decodeFailed)
        }
        // 4. I-save sa cache
        cache.setImage(image, for: url)
        return .success(image)
    }
}

MediaService ay ine-encapsulate ang isang proseso na may tatlong hakbang: cache → pag-load → pag-decode. Tumatawag ang UI ng isang method na loadImage(from:) sa halip na pamahalaan ang ImageCache, URLSession, at ImageDecoder. Sa pag-test, maaaring palitan ang MediaServiceProtocol ng mock na nagbabalik ng mga itinakdang imahe nang walang totoong pag-load.

Mga karaniwang pagkakamali sa paggamit ng Facade

Ang mga pagkakamali sa pagdidisenyo ng Facade ay sumisira sa mga bentahe nito: sa halip na pagpapasimple, lumilitaw ang isang God Object na pinagkakatiwalaan ng buong sistema. Tingnan natin ang tatlong pangunahing problema.

God Facade — labis na responsibilidad

Kapag ang isang Facade ay naglalaman ng mga method para sa pagpapatotoo, pag-load ng profile, pagpapadala ng mensahe, at pag-sync — ito ay isang God Object. Tanda: higit sa 15 pampublikong method sa isang klase. Solusyon: hatiin sa ilang espesyalisadong Facade ayon sa mga lugar ng responsibilidad — AuthService, ProfileService, MessagingService.

Facade na may paglabas ng mga detalye ng subsystem

Kung ang Facade ay nagbabalik ng mga type na tiyak sa subsystem (halimbawa, FirebaseUser o RealmObject), ang kliyente ay nakatali pa rin sa isang partikular na pagpapatupad. Solusyon: ang Facade ay dapat magbalik lamang ng sarili nitong mga type (data class / struct), na ganap na ina-abstrakta ang kliyente mula sa mga detalye ng subsystem.

Facade bilang nag-iisang entry point

Kapag ipinagbabawal ng Facade ang direktang pag-access sa subsystem, ito ay nagiging bottleneck. Minsan kailangan ng kliyente ang isang partikular na method ng subsystem, at ang pagpilit sa kanya na dumaan sa Facade ay labis. Ang Facade ay hindi dapat maging mahigpit na gatekeeper: nagbibigay ito ng maginhawang interface, ngunit hindi hinaharangan ang direktang pag-access sa mga component.