Facade: những điều cơ bản về mẫu mặt tiền trong kiến trúc di động

Mẫu Facade là gì?

Facade là một mẫu cấu trúc cung cấp một giao diện thống nhất cho một nhóm giao diện của hệ thống con. Nó định nghĩa một giao diện cấp cao giúp đơn giản hóa việc sử dụng hệ thống con. Facade không thêm chức năng mới — nó điều phối các thành phần hiện có, che giấu độ phức tạp trong tương tác của chúng khỏi khách hàng.

// Hệ thống con phức tạp
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 — một giao diện đơn giản cho 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 là một Facade che giấu AuthApi, UserDao và AnalyticsTracker khỏi ViewModel. UI gọi loginUser(email, password) thay vì ba yêu cầu riêng biệt tới API, cơ sở dữ liệu và phân tích. Điều này giảm độ liên kết: nếu ngày mai AuthApi trở thành FirebaseAuth hoặc UserDao chuyển sang Room, chỉ có Facade thay đổi, còn UI thì không.

Facade trong kiến trúc di động: Service Layer

Service Layer là một triển khai phổ biến của Facade trong các ứng dụng di động. Nó đóng gói logic nghiệp vụ và sự phối hợp giữa các tầng. Trong Android, Service Layer thường được triển khai qua UseCase (Clean Architecture), còn trong iOS qua các protocol Manager hoặc Service.

AuthService kết hợp cả bốn thành phần. ViewModel gọi một phương thức duy nhất mà không biết rằng bên trong đang diễn ra yêu cầu mạng, ghi cơ sở dữ liệu, theo dõi và kiểm tra mạng. Khi kiểm thử, AuthService có thể được thay bằng mock, xác minh toàn bộ logic xác thực mà không cần tích hợp với các thành phần thực.

Facade vs Adapter vs Mediator

Facade, Adapter và Mediator là các mẫu cấu trúc, nhưng chúng giải quyết những bài toán khác nhau. Chúng thường bị nhầm lẫn vì cả ba đều đưa vào một đối tượng trung gian. Hãy phân tích sự khác biệt qua ví dụ một ứng dụng di động.

Facade không che giấu hệ thống con — khách hàng có thể truy cập trực tiếp AuthApi khi cần. Adapter bắt buộc thay đổi giao diện của Adaptee. Mediator điều phối các tương tác phức tạp giữa nhiều đối tượng có thể không biết về nhau.

Triển khai Facade bằng Kotlin cho Android

Việc triển khai Facade bằng Kotlin cho Android với Clean Architecture sử dụng UseCase làm điểm vào cho mỗi kịch bản nghiệp vụ. UseCase là một Facade che giấu repository, mapper và các phụ thuộc khác khỏi tầng UI.

// Repository cũng là một Facade, nhưng ở cấp thấp hơn
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 cho kịch bản nghiệp vụ
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 là một Facade cho kịch bản tải hồ sơ. Nó che giấu logic bộ nhớ đệm (local → remote), ánh xạ DTO → Entity → Profile và theo dõi phân tích. ViewModel gọi invoke(userId) và nhận được UserProfile đã sẵn sàng hoặc một lỗi. UseCase có thể được kiểm thử độc lập bằng cách thay repository bằng một đối tượng mock.

Triển khai Facade bằng Swift cho iOS

Facade trong iOS thường được triển khai dưới dạng Manager hoặc Service. Khác với Android, iOS sử dụng protocol để định nghĩa giao diện Facade, giúp dễ dàng thay thế các triển khai trong kiểm thử. Hãy xem một Facade làm việc với phương tiện — tải, lưu bộ nhớ đệm và hiển thị.

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. Kiểm tra bộ nhớ đệm
        if let cached = cache.image(for: url) {
            return .success(cached)
        }
        // 2. Tải dữ liệu
        let result = await downloader.download(from: url)
        guard case let .success(data) = result else {
            return .failure(MediaError.downloadFailed)
        }
        // 3. Giải mã
        guard let image = decoder.decode(data) else {
            return .failure(MediaError.decodeFailed)
        }
        // 4. Lưu vào bộ nhớ đệm
        cache.setImage(image, for: url)
        return .success(image)
    }
}

MediaService đóng gói quy trình ba bước: bộ nhớ đệm → tải → giải mã. UI gọi một phương thức duy nhất loadImage(from:) thay vì quản lý ImageCache, URLSession và ImageDecoder. Khi kiểm thử, MediaServiceProtocol có thể được thay bằng mock trả về các ảnh định sẵn mà không cần tải thực tế.

Những lỗi điển hình khi sử dụng Facade

Những lỗi trong thiết kế Facade làm mất đi lợi ích của nó: thay vì đơn giản hóa, bạn nhận được một God Object mà toàn hệ thống phụ thuộc vào. Hãy phân tích ba vấn đề chính.

God Facade — quá nhiều trách nhiệm

Khi một Facade duy nhất chứa các phương thức xác thực, tải hồ sơ, gửi tin nhắn và đồng bộ hóa — đó là một God Object. Dấu hiệu: hơn 15 phương thức công khai trong một lớp. Giải pháp: chia nó thành nhiều Facade chuyên biệt theo các lĩnh vực trách nhiệm — AuthService, ProfileService, MessagingService.

Facade làm rò rỉ chi tiết hệ thống con

Nếu Facade trả về các kiểu đặc thù của hệ thống con (ví dụ, FirebaseUser hoặc RealmObject), khách hàng vẫn bị ràng buộc vào một triển khai cụ thể. Giải pháp: Facade chỉ nên trả về các kiểu của riêng nó (data class / struct), trừu tượng hóa hoàn toàn khách hàng khỏi chi tiết hệ thống con.

Facade như điểm vào duy nhất

Khi Facade cấm truy cập trực tiếp vào hệ thống con, nó trở thành nút thắt cổ chai. Đôi khi khách hàng cần một phương thức đặc thù của hệ thống con, và bắt họ phải đi qua Facade là thừa. Facade không nên là người gác cổng nghiêm ngặt: nó cung cấp một giao diện thuận tiện, nhưng không chặn truy cập trực tiếp vào các thành phần.