كيفية تصميم البرامج، التي يسهل التحكم بها

تخضع الحلول الرقمية للعديد من التغييرات خلال دورة حياتها. لتسهيل هذه التغييرات، يجب على المطورين اتباع المبادئ الخمسة SOLID لتصميمٍ جيدٍ للبرمجيات.

بقلم رنا الحنيس وحمزة رباح، مطورين في L-One

يتطور المنتج البرمجي الناجح باستمرار. يتم تحسينه وإضافة وظائف جديدة وواجهات إضافية، وأكثر من ذلك. ومع ذلك، إذا لم يتم إعداد البرمجيات بحرص منذ البداية، فإن تنفيذ هذه التغييرات يصبح أكثر صعوبة مع مرور الوقت.

لتجنب هذه المشكلة، ينبغي اتباع المبادئ الخمسة SOLID لتصميمٍ جيدٍ للبرمجيات، التي قدمها المطور الأمريكي، المستشار في تقنيات المعلومات، والكاتب روبرت سي. مارتن في عام 2000.

استناداً إلى هذه المبادئ، يتم إنشاء برمجيات توفر المزايا التالية:

• سهولة الصيانة والاختبار
• سهولة التوسع وإعادة الاستخدام
• سهولة الفهم

يعرّف روبرت سي. مارتن المبدأ الأول كما يلي:

"لا ينبغي أن يكون هناك أكثر من سبب لتعديل الفئة."

ومع ذلك، عادةً ما يُوصَف هذا المبدأ بطرق متعددة. تشمل الصيغ الأخرى:

"يجب أن يكون للوحدة مسؤولية واحدة فقط، ولا شيء سوى ذلك."

"اجمع الأشياء التي تتغير لأسباب متشابهة. وفرّق بين الأشياء التي تتغير لأسباب مختلفة."

يعمل مطوروا أنظمة L-One باستمرار على تحسين مهاراتهم في تصميم البرمجيات، مثل تطبيق مبادئ SOLID. يخصصون 10% من وقت عملهم للتعليم المستمر.

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

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

يعرّف مارتن «المسؤولية» على أنها سبب للتغيير ويخلص إلى أنه يجب أن يكون لدى الفئة/الوحدة سبب واحد فقط للتغيير. إذا كان من الممكن العثور على أكثر من سبب لتغيير الفئة، فلا بد أن هذه الفئة لديها أكثر من مسؤولية. يصعب رؤية هذا أحياناً لأننا معتادون على التفكير في المسؤوليات في مجموعات.

ما هي المشكلة إذا كان للفئة/الوحدة أكثر من مسؤولية واحدة ؟ لماذا من المهم تقسيم هذه المسؤوليات إلى فئات/وحدات متعددة ؟

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

نتيجة لذلك، سيتطلب تنفيذ التغييرات الكثير من الجهد.

وتوضّح الحالة التالية المشاكل التي تحدث عندما لا يتبع المطورون مبدأ المسؤولية الواحدة.

تخيل أن لدينا فئة «شخص» منظمة كما هو موضح في الشكل أدناه:

ينتهك هذا التصميم أول مبادئ SOLID، مبدأ المسؤولية الفردية (SRP)

ويبين الشكل أن فئة الأشخاص لها مسؤوليتان. الأول هو إبلاغ الموارد البشرية بساعات، والثاني يوفر وظائف كشوف المرتبات للمحاسبة. تستخدم كلتا الوظيفتين طريقة الساعات العادية، والتي تعيد ساعات العمل العادية للموظفين، بما في ذلك أوقات الاستراحة.

من خلال دمج الشفرة الرقمية المصدرية لهاتين المسؤوليتين في فئة «شخص» واحدة، قام المطورون بربط الفاعلين، الموارد البشرية والمحاسبة.

يعرّف روبرت سي. مارتن المبدأ الثاني على النحو التالي:

«يجب أن تكون كيانات البرمجيات (الفئات والوحدات والوظائف وما إلى ذلك) مفتوحة للتوسيع ولكنها مغلقة أمام التغيير».

روبرت سي مارتن

إذا أدى تغيير واحد في تطبيق ما إلى سلسلة من التغييرات في الوحدات المعتمدة - بعبارة أخرى، فرض تغييرات هائلة على البرنامج - فإن التصميم ليس مثالياً.

عندما يتم تطبيق مبدأ الفتح-الإغلاق بدقّة، يتم تحقيق التغييرات عن طريق إضافة رمز جديد، وليس عن طريق تغيير الشفرة الرقمية القديمة التي تعمل بالفعل.

زيادة المرونة وإمكانية إعادة الاستخدام والصيانة

والهدف من مبدأ الفتح-الإغلاق هو جعل النظام قابلاً للتوسع دون إجراء تغييرات جذرية.

يؤدي تطبيق هذا المبدأ إلى أكبر المزايا المنسوبة إلى التقنية الموجهة نحو الشيء: المرونة وإمكانية إعادة الاستخدام والصيانة.

تتميز الفئات/الوحدات التي تتوافق مع مبدأ الفتح-الإغلاق بخاصتين أساسيتين:

1) مفتوحة للتوسيع:

يمكن توسيع سلوك الوحدة. أي أنه مع تغير المتطلبات، يمكن توسيع الوحدة لتشمل سلوكيات جديدة لتلبية تلك التغييرات. أي أن المطورين قادرون على تغيير سلوك الوحدة.

2) مغلقة للتغيير:

إن إضافة أو توسيع سلوك هذه الوحدات لا يغير شفرتها الرقمية الأساسية، أي أن الشكل القابل للتنفيذ للوحدات لم يتغير.