كيف تشكل مبادئ SOLID أساس بناء برمجيات قوية ومستدامة؟

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

مع تطور عملية كتابة البرمجيات من المجال النظري إلى المجال الهندسي الحقيقي، ظهرت مجموعة من المبادئ التي تساعد في الحفاظ على قيمة الكود البرمجي (1). منها المبادئ الصلبة (SOLID Principles)، وهي مبادئ معينة لتصميم الأصناف (Classes). تساعد هذه المبادئ في إدارة الاعتمادية (Dependency management)، إذ تُعد إدارة الاعتمادية فن جعل الكود البرمجي مرنًا وقويًّا وقابلًا لإعادة الاستخدام (2). 

ومن ثم يمكّننا استخدام هذه المبادئ من بناء برامج فعالة وغير هشة ومستدامة وقابلة للصيانة؛ لتلبية الاحتياجات على المدى الطويل. 

تُعبّر كلمة SOLID اختصارًا عن المبادئ الأساسية الخمسة، فكل حرف يرمز إلى مبدأ معين: 

• S يرمز إلى SRP ويعني مبدأ المسؤولية الفردية Single Responsibility Principle.
• O يرمز إلى OCP ويعني المبدأ المفتوح والمغلق Open Closed Principle
• L يرمز إلى LSP ويعني مبدأ استبدال ليسكوف Liskov Substitution Principle
•  I يرمز إلى ISP ويعني مبدأ فصل الواجهة Interface Segregation Principle
• D يرمز إلى DIP ويعني مبدأ انعكاس التبعية Dependency Inversion Principle (3)

مبدأ المسؤولية الفردية Single Responsibility Principle:

تعني أن كل كائن (Object) يجب أن يكون له مسؤولية واحدة فقط يقوم بها، فكلما كان كود الصنف Class أطول كان تحقيق هذا المبدأ أصعب. ويُعد الصنف المسؤول عن تنفيذ أكثر من وظيفة هش التصميم مما قد يؤدي إلى نتائج غير متوقعة لأي وظيفة من وظائفه (1,4). 

المبدأ المفتوح والمغلق Open Closed Principle:

يجب أن تكون الكيانات البرمجية (classes, modules and functions) قابلة للتوسع  extension، ولكنها مغلقة للتعديل modification.

فإذا أدى تعديل واحد في برنامج ما إلى سلسلة من التغييرات في الوحدات modules التابعة، فإن هذا البرنامج يصبح هشًّا، أي لا يمكن التنبؤ به، وغير قابل لإعادة الاستخدام.

ولهذا يقول المبدأ المفتوح المغلق إنه يجب تصميم الوحدات modules بحيث لا تتغير أبدًا. وعندما تتغير المتطلبات، يمكن توسيع سلوك هذه الوحدات modules عن طريق إضافة تعليمات برمجية جديدة، وليس عن طريق تغيير التعليمات البرمجية القديمة التي تكون قيد التشغيل (4).

مبدأ استبدال ليسكوف Liskov Substitution Principle:

ينص هذا المبدأ على أنه يجب أن تكون التوابع (Functions) التي تستخدم مؤشرات (references) لصنف الأب قادرة على استخدام الأغراض Objects من الصنف المشتق (الابن) وبدون أن تتحقق من أنها أغراض من صنف مشتق، أي أن الكود البرمجي التابع الذي يتعامل مع مؤشرات لصنف الأب لا يحتاج إلى أي تعديل للتعامل مع أغراض لصنف الابن.

أما التوابع Functions التي تستخدم مؤشرات لصنف الأب ولكنها تتحقق بشكل خاص من الأصناف المشتقة (الأبناء) من الصنف الأب فهي تنتهك مبدأ استبدال ليسكوف. ويجب العلم بأن انتهاك مبدأ استبدال ليسكوف يعني أيضًا انتهاك المبدأ السابق (2).

مبدأ فصل الواجهة Interface Segregation Principle:

ينص مبدأ فصل الواجهة على أنه لا ينبغي إجبار العملاء على الاعتماد على واجهات لا يستخدمونها، أي يجب أن يعرف العملاء فقط عن الواجهة التي تهمهم.

يمكن أن يؤدي أي تغيير في واجهة غير ذات صلة إلى تغيير غير مقصود في كود العميل، وهذا يؤدي إلى ارتباط غير مقصود بين جميع العملاء، وكلما كانت الواجهة أكبر، زاد احتمال أن تحتوي على طرائق (methods) لا يمكن لجميع المنفذين تحقيقها، وهذا هو جوهر مبدأ فصل الواجهة (1,3,4). 

مبدأ انعكاس التبعية Dependency Inversion Principle

ينص مبدأ انعكاس التبعية على أنه: 

• لا يجب أن تعتمد الوحدات (modules) عالية المستوى على الوحدات ذات المستوى المنخفض، وكلاهما يجب أن يعتمد على التجريدات (أصناف مجردة Abstractions). 
• لا يجب أن تعتمد التجريدات على التفاصيل، بل التفاصيل هي من يجب أن تعتمد على التجريدات. 

أي يجب علينا فصل الـ modules عالية المستوى عن الـ modules منخفضة المستوى، وإدخال طبقة التجريد (abstract class) بين الأصناف عالية المستوى والأصناف منخفضة المستوى لكي نحقق مبدأ انعكاس التبعية، وهكذا فإن كل وحدة من الطبقة عالية المستوى تستخدم الوحدة منخفضة المستوى من خلال الصنف المجرد (2,4).

وفي النهاية ومع التطور السريع للتطبيقات البرمجية خلال السنوات القليلة الماضية، تحوَّل التركيز نحو جعل التطبيق قابلًا للتوسيع والتطوير، فمن المهم أن يقوم التطبيق بتوسيع نطاق نفسه وفقًا لكفاءة السوق. ويمكن القول بأن تطبيق مبادئ التصميم SOLID معًا يمكن أن يقودنا إلى إنشاء نظام قابل للصيانة وقابل للتطوير بدرجة كبيرة (4). 

المصادر: