الاقتران (Coupling) في تطوير التطبيقات المحمولة — المفاهيم الأساسية والأنواع وكيفية التقليل منه

ما هو الاقتران

الاقتران (Coupling) هو مقياس يحدد مدى ارتباط وحدة أو فئة بأخرى. كلما زادت معرفة وحدة عن البنية الداخلية لوحدة أخرى، زاد الاقتران وزادت صعوبة تغيير النظام. في البنية جيدة التصميم، يجب أن يكون الاقتران ضئيلاً — تتفاعل الوحدات فقط من خلال واجهات محددة بدقة.

هناك جانبان للاقتران: الوارد (التبعيات الداخلية — كم وحدة تعتمد على هذه) والصادر (التبعيات الخارجة — على كم وحدة تعتمد هذه). يساعد تحليل هذه المقاييس في تحديد النقاط الساخنة في البنية حيث سيؤثر تغيير وحدة واحدة على العديد من الوحدات الأخرى. أدوات مثل IntelliJ Dependency Analyzer و Xcode Graph تصور هذه الاتصالات.

من المهم أن نفهم أن الاقتران الصفري مستحيل — يجب أن تتفاعل الوحدات بطريقة ما، وإلا فلن يكون نظاماً بل مجموعة من البرامج المعزولة. مهمة المهندس المعماري هي جعل الاقتران قابلاً للإدارة وشفافاً. المثالي: تتفاعل الوحدات فقط من خلال الواجهات وتمرر بيانات بسيطة فقط، دون معرفة البنية الداخلية لبعضها البعض. هذا يسمى الاقتران الضعيف (loose coupling).

أنواع الاقتران من الضعيف إلى القوي

ستة أنواع من الاقتران تشكل مقياساً من الأفضل إلى الأسوأ. يساعد فهم هذا المقياس في تقييم الكود الموجود واختيار اتجاه إعادة الهيكلة. معظم مشاريع التطبيقات المحمولة لها أنواع مختلطة من الاقتران، ومهمة المهندس المعماري هي استبدال الأنواع القوية تدريجياً بالأنواع الضعيفة.

Data coupling — أفضل نوع

Data coupling (الاقتران بالبيانات) — تتبادل الوحدات بيانات بسيطة فقط عبر معاملات الدوال. الوحدة أ تستدعي دالة الوحدة ب، وتمرر بيانات بدائية أو هياكل بسيطة، وتتلقى نتيجة. الوحدة أ لا تعرف كيف تم تنفيذ ب داخلياً. هذا هو النوع الأكثر رغبة من الاقتران: يقلل من تأثير التغييرات.

مثال: EmailValidator.isValid(email: String): Boolean. تمرر الفئة المستهلكة سلسلة وتتلقى قيمة منطقية، دون أي فكرة عن التعبيرات المنتظمة أو قواعد التحقق داخل المدقق. تغيير منطق التحقق لا يتطلب تغيير المستهلك — الاقتران ضئيل. الاقتران بالبيانات هو الهدف لجميع الواجهات العامة في التطبيق.

Stamp coupling — مقبول ولكنه ليس مثالياً

Stamp coupling (الاقتران بالختم) — تتبادل الوحدات كائنات مركبة ولكنها تستخدم جزءاً فقط من حقولها. الوحدة أ تمرر كائن User إلى دالة calculateDiscount، التي تستخدم فقط user.status. المشكلة: إذا تغير هيكل User (أضيف حقل إجباري)، فإن دالة calculateDiscount لا تتغير، لكن المستهلك الذي ينشئ كائن User يتغير.

من الناحية العملية، stamp coupling أمر لا مفر منه ومقبول إذا كان الكائن الممرر نموذج بيانات قياسي (Entity). تنشأ المشكلة عندما تتلقى وحدة كائن كاملاً فقط من أجل حقل واحد. في مثل هذه الحالات، من الأفضل تمرير القيمة المحددة مباشرة (data coupling). الحل هو تحليل استخدام الحقول من قبل الطرف المتلقي.

Control, External, Common و Content coupling

Control coupling — تمرر وحدة إلى أخرى علامة تتحكم في سلوكها (calculate(useNewAlgorithm: Boolean)). هذا أسوأ من stamp coupling لأن الوحدة المستهلكة يجب أن تعرف المتغيرات الداخلية للوحدة المُستدعاة. الحل: تقسيم الدالة إلى اثنتين — calculateWithNewAlgorithm() و calculateWithLegacyAlgorithm().

External coupling — تعتمد الوحدات على بروتوكول خارجي أو تنسيق بيانات أو API. جميع الوحدات التي تحلل نفس JSON أو تعمل مع نفس قاعدة البيانات لديها external coupling. لا يمكن تجنبه تماماً، ولكن يمكن عزله: إنشاء طبقة تعيين بين التنسيق الخارجي والنماذج الداخلية. Common coupling — تشارك الوحدات حالة عامة مشتركة. Content coupling — أسوأ نوع، عندما تقوم وحدة بتعديل البيانات الداخلية لوحدة أخرى مباشرة.

مقياس الاقتران من data (المثالي) إلى content (الكارثة) هو أداة عملية لمراجعات الكود. إذا رأيت common أو content coupling في مشروع — فهذه أهداف ذات أولوية لإعادة الهيكلة. data و stamp coupling مقبولان وموجودان في أي مشروع، لكن يجب التحكم في كميتهما.

لماذا الاقتران مهم في تطوير التطبيقات المحمولة

الاقتران العالي يحول التطوير إلى عملية بطيئة حيث يتطلب كل تغيير التحقق من عشرات الوحدات التي قد تتعطل. هذا مهم بشكل خاص في تطوير التطبيقات المحمولة: تتحديث المنصات سنوياً (مستوى API لأندرويد، iOS SDK)، والمكتبات ربع سنوياً، ومتطلبات العمل باستمرار. الاقتران الضعيف هو الطريقة الوحيدة للتعامل مع هذا التدفق من التغييرات دون تراجعات مستمرة.

مثال عملي: تطبيق محمول حيث تستورد جميع الشاشات NetworkingManager و DatabaseManager مباشرة. عند استبدال عميل HTTP من Retrofit إلى Ktor (أندرويد) أو من URLSession إلى Alamofire (iOS)، سيضطر المطور إلى تعديل كل شاشة. مع الاقتران الضعيف، يكفي تغيير تطبيق واحد مخفي خلف واجهة NetworkDataSource — لن يلاحظ المستهلكون الاستبدال.

تأثير الاقتران على اختبارات الوحدة هائل أيضاً. لا يمكن اختبار فئة ذات اقتران عالٍ (إنشاء تبعيات مباشر عبر المنشئ) بشكل معزول — فهي تسحب معها قاعدة البيانات والشبكة وواجهة المستخدم. لاختبار مثل هذه الفئة، يجب تشغيل محاكي وانتظار اختبارات التكامل. الفئة ذات الاقتران المنخفض تقبل التبعيات عبر حقن المنشئ ويمكن محاكاتها بسهولة.

// اقتران عالٍ — الفئة تنشئ تبعياتها بنفسها
class ProfileViewModelHigh {
    private val api = RetrofitApi()
    private val db = RoomDatabase.getInstance()
    private val cache = MemoryCache()
}

// اقتران منخفض — التبعيات تمرر عبر المنشئ
class ProfileViewModelLow(
    private val api: ApiService,
    private val db: DatabaseService,
    private val cache: CacheService
)

في الحالة الأولى، ProfileViewModelHigh مرتبط بشدة بتطبيقات محددة — استبدال Retrofit بـ Ktor يتطلب تغيير كود ViewModel. في الحالة الثانية، يعتمد ProfileViewModelLow فقط على الواجهات، التي يتم توفير تطبيقاتها من الخارج. اختبار الفئة الثانية بسيط: تمرير تطبيقات وهمية والتحقق من المنطق دون محاكي.

أنماط تقليل الاقتران

مبدأ عكس التبعية (D في SOLID) هو الأساس لتقليل الاقتران. ينص المبدأ على الاعتماد على التجريدات، وليس على التطبيقات الملموسة. بدلاً من أن تقوم فئة بإنشاء كائن RetrofitApi مباشرة، يجب أن تستقبل واجهة ApiService. هذا ينقل التبعية من مكتبة محددة إلى مستوى التجريد، والذي يمكن استبداله دون تغيير المستهلك.

نمط Observer (أو إصداراته التفاعلية — StateFlow, Combine Publishers) يقلل الاقتران بين مصدر البيانات والمشتركين. لا يعرف المشترك من أين تأتي البيانات — إنه يتفاعل ببساطة مع التغييرات. هذا يفصل بين المرسل والمستقبل: يمكن إضافة مصدر بيانات جديد دون تغيير المشتركين الحاليين. EventBus و SharedFlow يعملان بنفس المبدأ.

نمط Bridge يفصل التجريد عن التطبيق، مما يسمح لهما بالتغيير بشكل مستقل. في تطوير التطبيقات المحمولة، يُستخدم Bridge مثلاً للوحدات المعتمدة على المنصة: واجهة مشتركة ImageLoader مع تطبيقات مختلفة لنظام iOS (Kingfisher, Nuke) وأندرويد (Glide, Coil). الكود الذي يعمل مع ImageLoader لا يعتمد على المكتبة المختارة ويمكن استبدالها بتغيير بسيط للتطبيق.

حقن التبعية كأداة لإدارة الاقتران

حقن التبعية (DI) هي الأداة الأكثر عملية لتقليل الاقتران في تطوير التطبيقات المحمولة. بدلاً من أن تقوم فئة بإنشاء تبعياتها بنفسها، يوفر حاوية DI (Hilt, Koin, Dagger لأندرويد؛ Swinject, Factory لنظام iOS) هذه التبعيات من الخارج. تتلقى الفئة التبعيات عبر حقن المنشئ أو الدالة أو الخاصية، دون معرفة التطبيقات الملموسة.

حقن التبعية يوثق بشكل صريح تبعيات الفئة: يكفي النظر إلى المنشئ لفهم الوحدات التي تتفاعل معها الفئة. إذا كان المنشئ يقبل 8 معاملات من طبقات مختلفة — فهذه إشارة على اقتران مفرط يتطلب إعادة هيكلة. الممارسة الجيدة هي ألا يزيد عن 3-4 تبعيات لكل فئة. عدد أكبر يشير إلى انتهاك مبدأ المسؤولية الواحدة واقتران مفرط.

حقن التبعية أيضاً يبسط الاختبار: لكل اختبار تقوم بإنشاء فئة مع تبعيات وهمية، دون الحاجة إلى قاعدة بيانات أو شبكة حقيقية. في Flutter يتم تطبيق DI عبر Provider أو Riverpod أو GetIt. بغض النظر عن الإطار، الهدف واحد: تقليل الاقتران بين الوحدات عن طريق جعل التبعيات صريحة وقابلة للاستبدال. استخدام DI في مشروع تطبيق محمول هو المعيار الفعلي منذ العقد 2020.

// حاوية DI تبني رسم بياني للتبعيات
protocol AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User
}

final class AuthService: AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User {
        // تطبيق
    }
}

// ViewModel لا تعرف الخدمة المحددة — فقط البروتوكول
final class LoginViewModel {
    private let auth: AuthServiceProtocol

    init(auth: AuthServiceProtocol) {
        self.auth = auth
    }
}

// DI Container هو المكان الوحيد حيث يتم إنشاء الأنواع الملموسة
final class DIContainer {
    lazy var authService: AuthServiceProtocol = AuthService()
    lazy var loginViewModel: LoginViewModel {
        LoginViewModel(auth: self.authService)
    }
}

هنا، LoginViewModel يعتمد فقط على بروتوكول AuthServiceProtocol، وليس على AuthService محدد. استبدال التطبيق (على سبيل المثال، الانتقال من Firebase Auth إلى خادم مخصص) يتطلب تغييرات فقط في DIContainer. جميع مستهلكي AuthServiceProtocol يظلون دون تغيير — يتم تقليل الاقتران إلى الحد الأدنى من خلال التجريد وحقن التبعية.