Facade: основи на модела фасада в мобилната архитектура

Какво е моделът Facade?

Facade — структурен модел, който предоставя единен интерфейс към група интерфейси на подсистемата. Той определя интерфейс на високо ниво, който опростява използването на подсистемата. Facade не добавя нова функционалност — той оркестрира съществуващите компоненти, скривайки от клиента сложността на тяхното взаимодействие.

// Сложна подсистема
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 — прост интерфейс за 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, който скрива AuthApi, UserDao и AnalyticsTracker от ViewModel. UI извиква loginUser(email, password) вместо три отделни заявки към API, базата данни и аналитиката. Това намалява свързаността: ако утре AuthApi стане FirebaseAuth или UserDao мигрира към Room, ще се промени само Facade, а не UI.

Facade в мобилната архитектура: Service Layer

Service Layer — разпространена реализация на Facade в мобилните приложения. Той капсулира бизнес логиката и координацията между слоевете. В Android Service Layer често се реализира чрез UseCase (Clean Architecture), в iOS — чрез Manager или протоколи Service.

AuthService обединява всичките четири компонента. ViewModel извиква един метод, без да знае, че под капака се извършва мрежова заявка, запис в базата данни, проследяване и проверка на мрежата. При тестване AuthService може да се замени с mock и да се провери цялата логика на автентикацията без интеграция с реалните компоненти.

Facade vs Adapter vs Mediator

Facade, Adapter и Mediator — структурни модели, но решават различни задачи. Те често се бъркат, тъй като и трите въвеждат посреднически обект. Нека разгледаме разликите на примера на мобилно приложение.

Facade не скрива подсистемата — клиентът може да получи директен достъп до AuthApi при необходимост. Adapter задължително променя интерфейса на Adaptee. Mediator координира сложни взаимодействия между множество обекти, които може да не знаят един за друг.

Реализация на Facade на Kotlin за Android

Реализацията на Facade на Kotlin за Android с Clean Architecture използва UseCase като входна точка за всеки бизнес сценарий. UseCase е Facade, който скрива хранилището, мапъра и другите зависимости от UI слоя.

// Repository — също Facade, но едно ниво по-ниско
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 за бизнес сценария
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 за сценария на зареждане на профила. Той скрива логиката на кеширане (local → remote), мапирането DTO → Entity → Profile и проследяването на аналитиката. ViewModel извиква invoke(userId) и получава готов UserProfile или грешка. UseCase може да се тества изолирано, като хранилището се замени с mock обект.

Реализация на Facade на Swift за iOS

Facade в iOS често се реализира като Manager или Service. За разлика от Android, iOS използва протоколи за дефиниране на интерфейса на Facade, което позволява лесна замяна на реализациите в тестовете. Нека разгледаме Facade за работа с медия — зареждане, кеширане и показване.

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. Провери кеша
        if let cached = cache.image(for: url) {
            return .success(cached)
        }
        // 2. Зареди данните
        let result = await downloader.download(from: url)
        guard case let .success(data) = result else {
            return .failure(MediaError.downloadFailed)
        }
        // 3. Декодирай
        guard let image = decoder.decode(data) else {
            return .failure(MediaError.decodeFailed)
        }
        // 4. Запази в кеша
        cache.setImage(image, for: url)
        return .success(image)
    }
}

MediaService капсулира процес от три стъпки: кеш → зареждане → декодиране. UI извиква един метод loadImage(from:) вместо да управлява ImageCache, URLSession и ImageDecoder. При тестване MediaServiceProtocol може да се замени с mock, който връща предварително зададени изображения без реално зареждане.

Типични грешки при използването на Facade

Грешките при проектирането на Facade анулират неговите предимства: вместо опростяване се получава God Object, от който зависи цялата система. Нека разгледаме три основни проблема.

God Facade — твърде много отговорности

Когато един Facade съдържа методи за автентикация, зареждане на профил, изпращане на съобщения и синхронизация — това е God Object. Признак: повече от 15 публични метода в един клас. Решение: разделяне на няколко специализирани Facade по области на отговорност — AuthService, ProfileService, MessagingService.

Facade с изтичане на детайли на подсистемата

Ако Facade връща типове, специфични за подсистемата (например FirebaseUser или RealmObject), клиентът все пак е обвързан с конкретна реализация. Решение: Facade трябва да връща само собствени типове (data class / struct), напълно абстрахирайки клиента от детайлите на подсистемата.

Facade като единствена входна точка

Когато Facade забранява директния достъп до подсистемата, той се превръща в тясно място. Понякога клиентът се нуждае от специфичен метод на подсистемата и да го принуждаваме да минава през Facade е излишно. Facade не трябва да бъде строг пазач: той предоставя удобен интерфейс, но не блокира директния достъп до компонентите.