Factory: جوهر نمطي Factory Method وAbstract Factory

ما هو Factory: جوهر نمط إنشاء الكائنات؟

Factory — نمط تصميم إنشائي من كتالوج GoF. الفكرة الرئيسية: نقل منطق إنشاء الكائنات من كود العميل إلى أسلوب أو فئة منفصلة. يعمل العميل مع واجهة أو فئة مجردة، بينما يتم إنشاء التطبيق المحدد بواسطة المصنع. هذا يحقق مبدأ عكس التبعية: العميل لا يعتمد على فئات محددة، فقط على التجريدات.

نوعان من Factory: Factory Method وAbstract Factory. Factory Method — أسلوب واحد في فئة تجاوزه الفئات الفرعية لإنشاء كائنات. Abstract Factory — واجهة مع عائلة من طرق المصنع لإنشاء مجموعات من الكائنات المترابطة. كلا النوعين يحلان نفس المشكلة: العميل لا يستدعي new MyClass() مباشرة، بل يطلب من المصنع إنشاء كائن حسب نوعه أو معلماته.

Factory vs new() — الإنشاء المباشر للكائنات يربط الكود بقوة بتطبيق محدد. يضيف Factory طبقة: تغيير التطبيق يتطلب تعديل المصنع فقط، وليس جميع العملاء. في تطوير التطبيقات المحمولة، يُستخدم Factory بنشاط لإنشاء ViewModel (ViewModelProvider.Factory) وعملاء الشبكة (Retrofit.create()) ومحولات القوائم ومصانع التسلسل. حاويات DI (Dagger, Koin) تولد المصانع تلقائياً.

Factory Method: أمثلة بلغة Swift وKotlin

Factory Method — أسلوب معلن في بروتوكول أو فئة مجردة يعيد كائنًا من نوع محدد. تنفذ الفئات الفرعية الأسلوب، مما ينشئ مثيلات محددة. في Swift، يمكن أن يكون أسلوبًا ثابتًا في بروتوكول أو أسلوبًا في فئة أساسية. في Kotlin — companion object مع أسلوب مصنع أو open fun في فئة مجردة. يُستخدم النمط على نطاق واسع لإنشاء المحللات ومصانع الأخطاء ومنشئي الاستعلامات.

protocol PaymentGateway {
    func processPayment(amount: Decimal) async throws -> PaymentResult
}

final class StripeGateway: PaymentGateway { /* ... */ }
final class ApplePayGateway: PaymentGateway { /* ... */ }

enum PaymentType { case stripe, applePay }

final class PaymentFactory {
    // Factory Method
    static func create(type: PaymentType) -> PaymentGateway {
        switch type {
        case .stripe: return StripeGateway()
        case .applePay: return ApplePayGateway()
        }
    }
}

// الاستخدام
let gateway = PaymentFactory.create(type: .stripe)

نسخة Kotlin من Factory Method تستخدم companion object أو sealed class لتحديد الأنواع. تضمن sealed class أن فرع when يغطي جميع الأنواع الممكنة — يتحقق المترجم من الاكتمال. هذا نموذجي لمشاريع Android حيث ينشئ المصنع تطبيقات مختلفة من Repository أو DataSource حسب build flavour أو التكوين.

sealed class PaymentType {
    object Stripe : PaymentType()
    object ApplePay : PaymentType()
}

interface PaymentGateway {
    suspend fun processPayment(amount: BigDecimal): PaymentResult
}

class PaymentFactory {
    companion object {
        fun create(type: PaymentType): PaymentGateway = when (type) {
            PaymentType.Stripe -> StripeGateway()
            PaymentType.ApplePay -> ApplePayGateway()
        }
    }
}

Abstract Factory: عائلات الكائنات المترابطة

Abstract Factory — نمط لإنشاء عائلات من الكائنات المترابطة أو المترابطة دون تحديد فئاتها المحددة. يعمل العميل مع واجهة المصنع المجرد، الذي يحدد طرقًا لإنشاء كل منتج من العائلة. ينفذ مصنع محدد الواجهة وينشئ كائنات من نسخة محددة. على سبيل المثال، مصنع مكونات واجهة المستخدم لنظام iOS ينشئ UIButton وUILabel وUITableView، بينما لنظام Android — Button وTextView وRecyclerView.

Abstract Factory vs Factory Method — ينشئ Factory Method نوعًا واحدًا من الكائنات من خلال الوراثة، وينشئ Abstract Factory عائلة من الكائنات من خلال التركيب. يتم تجاوز Factory Method في الفئات الفرعية، ويوفر Abstract Factory طرق مصنع متعددة من خلال بروتوكول. غالبًا ما يحتوي Abstract Factory على عدة Factory Method. في تطوير التطبيقات المحمولة، يُستخدم Abstract Factory للمكونات المعتمدة على المنصة وسمات التصميم ومصانع قواعد البيانات.

حالة واقعية لـ Abstract Factory في Android — تنفيذ أنواع مختلفة من قواعد البيانات (SQLite vs Room) من خلال واجهة DatabaseFactory واحدة. ينشئ المصنع كائنات DAO وعمليات الترحيل ومجموعات الاتصال. في iOS — مصنع خدمات لبيئات مختلفة (Development/Staging/Production). نادراً ما يُستخدم Abstract Factory مباشرة — وظائفه تتولاها حاويات DI (Dagger Module, Swinject Assembly).

Factory في iOS: البروتوكولات والطرق الثابتة

Swift Factory يتم تنفيذه من خلال البروتوكولات والطرق الثابتة. يعلن بروتوكول Factory عن أسلوب create() يعيد نوعًا مجردًا. ينفذ مصنع محدد البروتوكول وينشئ الكائنات المطلوبة. لا تتطلب Swift فئة مصنع منفصلة للحالات البسيطة — أسلوب ثابت في enum أو struct يكفي. للسيناريوهات المعقدة، يُستخدم بروتوكول Factory مع حقن DI.

Factory في iOS SDK — العديد من مصانع النظام: UIStoryboard.instantiateViewController(withIdentifier:) وNSKeyedUnarchiver.unarchivedObject(ofClass:from:) وJSONDecoder().decode(_:from:). ينشئ المطورون مصانع لـ ViewController (StoryboardFactory) وللخدمات (ServiceFactory) ولنماذج البيانات. يُستخدم Factory Method بنشاط في معماريتي VIPER وClean Swift لإنشاء وحدات الشاشات.

Factory + DI — بديل حديث: حاوية DI (Swinject, Factory) تولد تلقائياً مصانع للأنواع المسجلة. تخزن الحاوية وصفات إنشاء الكائنات وتحل التبعيات. مكتبة Factory (github.com/hmlongco/Factory) تستخدم @Injected(.service) للحقن التلقائي. تُختبر مصانع DI باستبدال وحدة كاملة بسطر واحد: container.register { MockService() }.

Factory في Android: companion factory ووحدات DI

Android Factory — مثال كلاسيكي: ViewModelProvider.Factory لإنشاء ViewModel بمعلمات. توصي Google باستخدام Hilt للتوليد التلقائي لمصانع ViewModel — تُنشئ @HiltViewModel التعليق التوضيحي Factory تلقائياً. للكائنات البسيطة، يُستخدم companion object مع أسلوب create() أو invoke(). في Kotlin، يسمح عامل invoke باستدعاء المصنع كدالة: Factory(param).

Factory في Jetpack Compose — تُستخدم المصانع لإنشاء الحالات والتأثيرات. remember { Factory.create() } ينشئ كائنًا عند أول عرض ويحافظ عليه طوال دورة حياة composable. يتم إنشاء ViewModel في Compose عبر viewModel() — هذا مصنع يديره Hilt. في Compose، تكون المصانع أقل شيوعًا بشكل صريح، حيث أن DI وCompose StateManager يتوليان إنشاء الكائنات.

Factory vs Hilt — Dagger/Hilt يولد المصانع تلقائياً في وقت الترجمة. @Module + @Provides يحل محل Factory Method، @Binds يحل محل Abstract Factory. تظل المصانع اليدوية ذات صلة للاختيار الديناميكي للتطبيق في وقت التشغيل (اختبار A/B، feature flags). للتبعيات الثابتة، يقوم Hilt بأتمتة إنشاء الكائنات بالكامل — يكتب المطور فقط الواجهات والتعليقات التوضيحية.