SoC في التطوير المحمول: ما هو، المبادئ وفصل المسؤوليات

ماذا يعني اختصار SoC

SoC يرمز إلى Separation of Concerns: «فصل المسؤوليات» أو «فصل مجالات الاهتمام». في سياق التطوير، يشير مصطلح concern إلى أي وظيفة قابلة للفصل: عرض واجهة المستخدم، معالجة النقرات، التحقق من البيانات، التواصل الشبكي أو العمل مع قاعدة البيانات. يفرض مبدأ SoC تجميع الكود حول هذه المجالات بحيث لا تؤثر التغييرات في أحدها على الآخرين.

يستخدم اختصار SoC على نطاق واسع في الأدبيات التقنية والنقاشات المعمارية وتوثيق الأطر. على سبيل المثال، في توثيق Android Architecture Components، يذكر SoC مرارًا كدافع لفصل ViewModel عن View. في مجتمع iOS، يستخدم المصطلح عند مناقشة مشكلة Massive View Controller — النتيجة المباشرة لغياب SoC.

من المهم أن نفهم أن SoC ليس إجراءً لمرة واحدة، بل عملية مستمرة. مع نمو التطبيق، تظهر مجالات مسؤولية جديدة، ويجب إعادة النظر في المعمارية. قاعدة الكود الجيدة تمر بعدة تكرارات من الفصل قبل الوصول إلى حالة مستقرة حيث يكون كل concern معزولاً وقابلاً للإدارة.

SoC مقابل Separation of Concerns

Separation of Concerns واختصاره SoC يشيران إلى نفس المبدأ. الفرق الوحيد هو سياق الاستخدام: الاسم الكامل يُستخدم في المستندات الرسمية والمواد التعليمية وعند شرح المفهوم لأول مرة للمطورين الجدد. SoC مناسب في النقاشات التقنية ومراجعات الكود والتوثيق حيث تكون الإيجاز مهمًا.

في البيئة المهنية، كلا المصطلحين قابلان للتبادل. يمكن للمطور أن يقول «هذا ينتهك SoC» أو «هذا ينتهك Separation of Concerns» — المعنى لا يتغير. ومع ذلك، في إعلانات الوظائف ومتطلبات المعمارية، يُستخدم الاسم الكامل في الغالب، بينما في الدردشات ومراجعات الكود يُستخدم الاختصار. معرفة كلا الخيارين ضرورية لدخول مريح إلى المجال.

يوجد التباس مصطلحي: اختصار SoC يُستخدم أيضًا في السياق العتادي لـ System-on-a-Chip (نظام على رقاقة). في التطوير المحمول، السياق دائمًا واضح من البيئة — إذا كان النقاش حول معمارية الكود، فهو يشير إلى Separation of Concerns. في هذه المقالة، يشير SoC دومًا إلى مبدأ فصل المسؤوليات.

كيف يطبق SoC في المعمارية المحمولة

المعمارية ثلاثية الطبقات هي الطريقة الأكثر شيوعًا لتطبيق SoC في التطبيقات المحمولة. تقسم الكود إلى Presentation (UI) و Domain (منطق الأعمال) و Data (مصادر البيانات). تحتوي كل طبقة على أنواع محددة بدقة من الفئات وتكون معزولة عن المجاورة عبر واجهات. هذا النهج فعال بنفس القدر لمشاريع iOS و Android و Flutter.

طبقة Presentation و ViewModel

View و ViewModel تشكلان طبقة العرض. View مسؤولة عن عرض الواجهة ونقل أحداث المستخدم. ViewModel تحفظ حالة الشاشة وتحول البيانات من طبقة Domain إلى تنسيق جاهز للعرض. ViewModel لا تحتوي على مراجع لـ Activity أو Fragment أو UIViewController — وهذا يضمن SoC بين UI والمنطق.

على سبيل المثال، في Android Jetpack، ViewModel ينجو من تدوير الشاشة بينما يتم إعادة إنشاء UI. بدون SoC، كان يجب حفظ الحالة في Activity، مما يخلط إدارة دورة الحياة بالبيانات. ViewModel يحل هذه المشكلة بشكل معزول، مظهرًا تطبيقًا نظيفًا لمبدأ فصل المسؤوليات.

طبقة Domain و Use Cases

Use Cases تحتوي على قواعد الأعمال المستقلة عن المنصة. هذه الطبقة لا تستورد Android SDK أو iOS UIKit أو Flutter framework. Use Case يستقبل البيانات من Repository، ويطبق منطق الأعمال، ويعيد النتيجة. بفضل SoC، يمكن إعادة استخدام Use Case واحد عبر شاشات ومنصات مختلفة.

مثال كلاسيكي هو ValidateAndSaveUseCase لنموذج التسجيل. يتحقق من صحة البريد الإلكتروني وكلمة المرور، يستدعي UserRepository للحفظ، ويعيد ValidationResult. لا UI ولا قاعدة البيانات تعرفان قواعد التحقق — فهي مركزة في مكان واحد، مما يسهل تغييرها.

طبقة Data و Repository

Repository يجرد مصادر البيانات من باقي التطبيق. ViewModel لا يعرف من أين تأتي البيانات — من REST API أو GraphQL أو قاعدة البيانات المحلية أو التخزين المؤقت. Repository يقرر أي مصدر يستخدم ويخفي هذا المنطق خلف واجهة. هذا هو SoC بين جلب البيانات واستهلاكها.

DataSource يوفر فصلًا أعمق: RemoteDataSource مسؤول فقط عن طلبات HTTP، LocalDataSource مسؤول عن العمل مع Room أو CoreData أو SharedPreferences. Repository يدمجها بتطبيق استراتيجيات التخزين المؤقت. يمكن استبدال كل DataSource بشكل مستقل، وهو أمر بالغ الأهمية عند الترحيل بين الخوادم أو قواعد البيانات.

نظام DataSource متعدد المستويات هذا يطبق SoC على مستوى البنية التحتية: التواصل الشبكي والتخزين المحلي والتخزين المؤقت هي concerns منفصلة، لكل منها منطقه ودورة حياته. عند استبدال عميل HTTP، يتغير RemoteDataSource فقط، بينما يبقى Repository والطبقات العليا دون تغيير، مما يؤكد القيمة العملية لفصل المسؤوليات.

SoC في الأنماط المعمارية

MVP (Model-View-Presenter) كان من أوائل الأنماط التي طبقت SoC صراحة في التطوير المحمول. Presenter يحتوي على المنطق ويتحكم في View عبر واجهة. View سلبية — تعرض فقط ما يخبرها به Presenter. الفصل يبسط الاختبار: Presenter يُختبر دون محاكي، وView تبقى بسيطة لدرجة أنه لا يوجد شيء يمكن أن يتعطل.

MVVM أضاف الربط التفاعلي: View تشترك في تغييرات ViewModel عبر Observable أو StateFlow. ViewModel لا يحتفظ بمرجع لـ View، مما يزيل خطر تسرب الذاكرة ويفصل concerns بقوة أكبر. في Android، أصبح MVVM المعيار بفضل Jetpack ViewModel و LiveData، وفي iOS — بفضل Combine و RxSwift.

Clean Architecture لروبرت مارتن تصل بـ SoC إلى فصل جذري في حلقات. الحلقة الخارجية (الأطر والمحركات) تعتمد على الداخلية (الكيانات)، ولكن ليس العكس. في الممارسة العملية، نادرًا ما تنفذ المشاريع المحمولة جميع الحلقات الأربع — يكفي Domain و Data حول Presentation. لكن مبدأ «الاعتماد نحو الداخل» يعطي مزايا كبيرة عند تغيير الأطر.

// View — عرض فقط، بدون منطق
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — يحتوي على منطق الشاشة، لا يعرف UIKit
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — منطق الأعمال، مستقل عن المنصة
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

المثال يظهر ثلاثة مستويات من SoC: LoginViewController فقط ينقل الأحداث، LoginViewModel يدير الحالة، LoginUseCase يحتوي على قواعد الأعمال. كل فئة تُختبر بشكل مستقل، وتغيير إطار UI لا يؤثر على Use Case.

انتهاكات SoC الشائعة في المشاريع المحمولة

Massive View Controller هو الانتهاك الأكثر شيوعًا لـ SoC في iOS. فئة تدير UI وتعالج طلبات الشبكة وتحلل JSON وتحفظ البيانات تنتهك المبدأ على جميع المستويات. الحل هو استخراج كل مسؤولية في مكون منفصل: NetworkingService و JSONParser و CoreDataStack، تاركًا ViewController فقط لإدارة View.

في Android، مشكلة مماثلة هي God Activity أو God Fragment. نشاط واحد يحمل البيانات ويحقق من النماذج ويعرض الحوارات ويحدث UI. يُعالج بإدخال ViewModel و Repository اللذين يتوليان إدارة الحالة والبيانات. ViewModel يحمي أيضًا من فقدان البيانات عند تدوير الشاشة.

الانتهاك الثالث هو خلط كود المنصة والأعمال. على سبيل المثال، وضع طلب HTTP مباشرة في SwiftUI View أو Android Composable. هذا يجعل الكود غير قابل للنقل وصعب الاختبار. النهج الصحيح هو نقل الطلب إلى Repository، الذي يُستدعى عبر Use Case، بينما View تشترك فقط في النتيجة. كل عنصر من النظام يحل مهمته الخاصة ولا يتجاوز حدوده.