مبادئ الهندسة المعمارية في التطوير المحمول: ما هي، أنواعها وكيفية تطبيقها

مبادئ SOLID

مبادئ الهندسة المعمارية — هي أساس الكود عالي الجودة. SOLID هو اختصار قدمه روبرت مارتن («العم بوب») يصف خمسة مبادئ للتصميم كائني التوجه. اتباع SOLID يجعل الكود أكثر مرونة وقابلية للاختبار ومقاومة للتغيير. انتهاك مبادئ الهندسة المعمارية هو أحد الأسباب الرئيسية للديون التقنية.

دعنا نفحص كل مبدأ. Single Responsibility Principle (SRP) — يجب أن يكون لكل فئة سبب واحد فقط للتغيير. Open/Closed Principle (OCP) — الفئات مفتوحة للتمديد ولكن مغلقة للتعديل. Liskov Substitution Principle (LSP) — يجب أن تحل كائنات الأنواع الفرعية محل كائنات النوع الأساسي دون كسر المنطق. Interface Segregation Principle (ISP) — واجهات متخصصة متعددة أفضل من واجهة عامة واحدة. Dependency Inversion Principle (DIP) — الاعتماد على التجريدات وليس على التطبيقات الملموسة.

وفقًا لتحليل SonarQube (2025)، يحدث انتهاك مبادئ SOLID في 68% من المشاريع التجارية. المشكلات الأكثر شيوعًا هي انتهاك SRP (35%) وISP (22%). في IT Sectr، نطبق SOLID في مرحلة مراجعة الهندسة المعمارية — وهذا يساعد في اكتشاف المشكلات قبل أن تتحول إلى ديون تقنية.

Single Responsibility Principle (SRP)

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

الانتهاك النموذجي هو فئة تعالج البيانات وتحفظها في قاعدة البيانات وترسل إشعارات البريد الإلكتروني في نفس الوقت. المثال أدناه يظهر انتهاك SRP في Kotlin وكيفية إصلاحه.

// انتهاك SRP — الفئة تقوم بثلاث مهام مختلفة
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. التحقق من البيانات
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. الحفظ في قاعدة البيانات
        val user = User(email, name)
        database.save(user)
        
        // 3. إرسال الإشعار
        emailService.sendWelcomeEmail(email, name)
    }
}

// الإصلاح — التقسيم إلى ثلاث فئات
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

في النسخة المصححة، كل فئة مسؤولة عن مهمتها الخاصة: UserValidator — عن التحقق، UserRepository — عن الحفظ، NotificationService — عن الإشعارات. هذا يجعل الكود قابلًا للاختبار وإعادة الاستخدام — يمكن استبدال تنفيذ قاعدة البيانات دون تغيير منطق التحقق.

GRASP وقانون ديمتر

GRASP (General Responsibility Assignment Software Patterns) — تسعة مبادئ هندسة معمارية لتوزيع المسؤولية بين الكائنات، وصفها كريج لارمان. على عكس SOLID، يجيب GRASP على السؤال «أي فئة يجب أن تحتوي على هذا الأسلوب؟». الأنماط الرئيسية: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

قانون ديمتر (LoD، مبدأ الحد الأدنى من الاقتران) — قاعدة بسيطة: يجب أن يتواصل الكائن فقط مع جيرانه المباشرين. لا يجب كتابة a.getB().getC().doSomething() — هذا يخلق اقترانًا قويًا بين الفئات. LoD يحسن إعادة الاستخدام ويبسط الاختبار.

في IT Sectr، نتحقق من الامتثال لـ LoD أثناء مراجعة الكود. إذا كان الأسلوب «يمر عبر» ثلاثة كائنات أو أكثر، فهذه إشارة إلى أن الهندسة المعمارية بحاجة إلى تبسيط. انتهاك LoD هو واحد من أكثر Code Smell شيوعًا في المشاريع الكبيرة.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) وYAGNI (You Ain't Gonna Need It) — ثلاثة مبادئ أساسية للهندسة المعمارية معروفة لكل مطور. على الرغم من بساطتها، تحدث الانتهاكات باستمرار.

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

KISS — كلما كان أبسط كان أفضل. الحلول المعقدة مع العديد من التجريدات والوراثات غالبًا ما تكون مفرطة. ابدأ بحل بسيط واجعله أكثر تعقيدًا فقط عند الضرورة. YAGNI — لا تكتب كودًا لوظائف قد تحتاجها «في وقت لاحق». هذا يؤدي إلى تضخم قاعدة الكود وزيادة تعقيد الصيانة.

DRY — Don't Repeat Yourself

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

في IT Sectr، نستخدم مقاييس تحليل الكود لاكتشاف التكرار. أدوات مثل SonarQube وDetekt تظهر نسبة الكود المكرر. قيمة أعلى من 5% هي سبب لإعادة الهيكلة. ومع ذلك، من المهم أن نتذكر: لا يجب تحقيق DRY على حساب تجريدات خاطئة — أحيانًا من الأفضل ترك قطعتين متشابهتين من الكود كما هما إذا كان دمجهما سيعقد الفهم.

فصل الاهتمامات والنمطية

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

النمطية — الدرجة التي يمكن بها تقسيم النظام إلى وحدات (موديولات). الوحدة هي مجموعة مترابطة منطقيًا من الفئات بواجهة محددة جيدًا. يجب أن تكون الوحدات منخفضة الاقتران (low coupling) وعالية التماسك (high cohesion).

التماسك مقابل الاقتران

التماسك — مقياس لمدى ارتباط العناصر داخل الوحدة الواحدة ببعضها البعض. التماسك العالي جيد: الفئة تفعل شيئًا واحدًا وتفعله جيدًا. الاقتران المنخفض — مقياس لمدى استقلالية الوحدات عن بعضها البعض. الاقتران المنخفض جيد: تغيير وحدة واحدة لا يكسر الأخرى.

الهندسة المعمارية المثالية هي تماسك عالي واقتران منخفض. من الناحية العملية، هذا يعني: الفئة تحتوي على أساليب تعمل على نفس البيانات (تماسك)، وتعتمد فقط على التجريدات وليس على التطبيقات الملموسة (اقتران). عدم التوازن يؤدي إلى «كائنات الله» (God Object) أو «كود السباغيتي».

الديون التقنية وCode Smell

الديون التقنية — استعارة قدمها وارد كانينغهام تصف «الفوائد» التي يدفعها الفريق مقابل قرارات الهندسة المعمارية غير المثلى وانتهاك مبادئ الهندسة المعمارية. مثل الديون المالية، يمكن أن تكون الديون التقنية مقصودة (قررنا القيام بذلك بسرعة، سنعيده لاحقًا) وغير مقصودة (هندسة معمارية سيئة بسبب نقص الخبرة).

Code Smell — علامات سطحية لمشاكل عميقة في الكود. المصطلح شاعه مارتن فاولر في كتاب «Refactoring». Code Smell النموذجية: أساليب طويلة، فئات كبيرة، سلاسل استدعاء طويلة، تكرار الكود، الاستخدام المفرط للتعليقات (بدلاً من الكود الواضح).

في IT Sectr، يتم تتبع الديون التقنية في Jira كمهام منفصلة. في كل سباق، نخصص 20% من الوقت لإعادة الهيكلة وسداد الديون. العمل المنهجي مع الديون التقنية هو الطريقة الوحيدة لتجنب المواقف التي يستغرق فيها إضافة ميزة جديدة وقتًا أطول من تطويرها من الصفر.