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 API، ڈیٹا بیس اور تجزیات کو تین الگ الگ درخواستیں بھیجنے کے بجائے loginUser(email, password) کو کال کرتا ہے۔ اس سے انحصار کم ہوتا ہے: اگر کل 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 بمقابلہ Adapter بمقابلہ Mediator

Facade، Adapter اور Mediator ساختی پیٹرن ہیں، لیکن مختلف مسائل حل کرتے ہیں۔ انہیں اکثر الجھایا جاتا ہے، کیونکہ تینوں ایک درمیانی شے متعارف کراتے ہیں۔ موبائل ایپلیکیشن کی مثال پر فرق کا تجزیہ کرتے ہیں۔

Facade ذیلی نظام کو نہیں چھپاتا — کلائنٹ ضرورت پڑنے پر AuthApi تک براہ راست رسائی حاصل کر سکتا ہے۔ Adapter لازمی طور پر Adaptee کا انٹرفیس تبدیل کرتا ہے۔ Mediator بہت سی اشیاء کے درمیان پیچیدہ تعاملات کو ہم آہنگ کرتا ہے، جو ایک دوسرے کے بارے میں نہیں جانتیں۔

Android کے لیے Kotlin میں Facade کا نفاذ

Facade کا نفاذ Kotlin میں Android کے لیے Clean Architecture کے ساتھ ہر کاروباری منظرنامے کے لیے داخلی نقطہ کے طور پر UseCase استعمال کرتا ہے۔ UseCase ایک Facade ہے جو ذخیرہ، مapper اور دیگر انحصار کو 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 شے سے بدل کر الگ تھلگ جانچا جا سکتا ہے۔

iOS کے لیے Swift میں Facade کا نفاذ

iOS میں Facade اکثر 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 ImageCache، URLSession اور ImageDecoder کے انتظام کے بجائے ایک ہی طریقہ loadImage(from:) کال کرتا ہے۔ جانچ کے وقت، 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 کو سخت گیٹ کیپر نہیں ہونا چاہیے: یہ ایک آسان انٹرفیس فراہم کرتا ہے، لیکن اجزاء تک براہ راست رسائی کو مسدود نہیں کرتا۔