هذا المقال هو أحد مقالات سلسلة “كيف شرحت التصميم الغرضي لزوجتي“
عمر: دعيني أريكِ هذه الصّورة أوّلاً. علينا أن نشكر الشّخص الذي صمم هذه الصّور, فهي مثيرة للاهتمام بالفعل:
كونك تستطيع فعل الشيء, لا يعني أنه يجب عليك فعله
إنّها تقول “إنّ قدرتك على وضع جميع الخصائص و المزايا في جهاز واحد, لا تعني أنّ فعل ذلك أمر جيد”. لماذا؟ لأنّ هذا العمل يضيف الكثير من المشاكل المتعلّقة بالقدرة على الإدارة[2] و ذلك على المدى الطّويل.
دعيني أترجم لك هذا المبدأ وفقاً للمصطلحات الغرضيّة التوجّه :
“يجب ألّا يكون هناك أكثر من سبب وحيد للتعديل على صنف ما”, أو بشكل آخر:
“الصنف يجب أن تكون له مسؤوليّة وحيدة”.
ريم: هل بإمكانك الشرح من بعد إذنك؟
عمر:بالطبع , هذا المبدأ يقول: إن كان أحد أصنافك يمتلك أكثر من سبب وحيد للتغيّر (أو أنّ له أكثر من مسؤوليّة وحيدة) فإن عليك تجزئته إلى عدّة أصناف تبعاً لمسؤوليّاتها.
ريم: ممم… هل هذا يعني أنني لا يجب أن أضع أكثر من طريقة واحدة في الصنف؟
عمر: هذا ليس صحيحاً على الإطلاق. بالطبع تستطيعين وضع عدّة طرائق في صنف واحد, الفكرة هي أنه يجب على هذه الطرائق جميعها أن تعمل لتحقيق هدف وحيد, الآن دعيني أقول لك لماذا تجزئة الصنف ضرورية:
إنّها ضرورية لأن:
- كل مسؤولية هي محور للتغيير[3].
- الشيفرة البرمجية تصبح مقترنةً[4] إذا كانت الأصناف تمتلك أكثر من مهمّة.
ريم: هل تستطيع أن تعطيني مثالاً.
عمر: بالطبع, انظري إلى هذه البنية الهرميّة للأصناف (في الواقع هذا المثال مأخوذ من Uncle Bob فالشكر الجزيل له):
بنية هرمية توضخ خرقاً لمبدأ المسؤولية الوحيدة
هنا, الصنف Rectangle يقوم بما يلي:
- يحسب مساحة المستطيل.
- يرسم المستطيل على واجهة المستخدم[5].
و هناك تطبيقان برمجيّان[6] يستخدمان الصنف Rectangle :
- تطبيق هندسي حسابي, يستخدم هذا الصنف في حساب المساحات.
- تطبيق رسومي, يستخدم هذا الصنف لرسم مستطيل على واجهة المستخدم.
هذا يخرق مبدأ المسؤوليّة الوحيدة.
ريم: كيف؟
عمر: كما ترين, إنّ الصنف Rectangle يقوم بأمرين متباينين تماماً, إنّه يقوم بحساب المساحة في إحدى الطرائق, كما أنّه يقوم بإعادة[7] تمثيل رسوميّ للمستطيل (GUI) في طريقة أخرى. إنّ هذا يقود إلى مجموعة مثيرة للاهتمام من المشاكل:
- عليكِ أن تُضمّني[8] الصنف الذي يعبّر عن التمثيل الرسومي للمستطيل (GUI) في التطبيق الهندسي الحسابي, ففي حين أنكِ تريدين استخدام التطبيق الهندسي الحسابي فأنت مضطرّة لتضمين مكتبة الـ GUI .
- إنّ تغييراً ما في الصنف Rectangle من أجل التطبيق الرسومي قد يؤدي إلى تغيير, و إعادة بناء[9], و اختبار في التطبيق الهندسي الحسابي, و العكس صحيح.
ريم: إن الأمر أصبح مثيراً للاهتمام. إذاً أنا أفترض بأنّه علينا أن نقسم الصنف بناء على مسؤوليّاته, أليس كذلك؟
عمر: تماماً, هل تستطيعين توقّع ماذا يجب علينا فعله؟
ريم: بالطبع.. دعني أحاول. فيما يلي سأذكر ماقد نحتاج لفعله:
فصل المسؤوليّات إلى صنفين مستقلّين, مثل:
- Rectangle: هذا الصنف يجب أن يعرّف الطريقة Area() .
- RectangleUI: هذا الصنف يجب أن يرث الصنف Rectangle و يعرّف الطريقة Draw() .
عمر: ممتاز. في هذه الحالة Rectangle سيستخدم في التطبيق الهندسي الحسابي, و RectangleUI سيستخدم في التطبيق الرسومي. بإمكاننا, حتّى, أن نفصل الصنفين ونضع كلّاً منهما في مكتبة DLL مختلفة, في مثل هذه الحالة سيمكننا التغيير في أحد الصنفين دون الحاجة للتغيير في الآخر.
ريم: شكراً, أشعر بأنني فهمت مبدأ المسؤوليّة الوحيدة, فكرة هذا المبدأ يبدو أنها تتمحور حول تقسيم الأشياء إلى وحدات أوّليّة بحيث تصبح قابلة لإعادة الاستخدام, و قابلة لتتم إدارتها مركزيّاً.
إذاً, أليس علينا تطبيق مبدأ المسؤوليّة الوحيدة على مستوى الطّرائق أيضاً؟ أقصد, قد نكون قد كتبنا طرائقاً تحتوي على أسطر شيفرة كثيرة جداً تقوم بمهمات متعددة, مثل هذه الطرائق تخترق مبدأ المسؤولية الوحيدة , أليس كذلك؟
عمر: لقد فهمتِ الأمر تماماً. عليك أن تقسّمي طرائقك بحيث تصبح كل طريقة مهتمة بتنفيذ عمل محدّد, هذا سيسمح لكِ بإعادة استخدام الطرائق, و في حال الحاجة لإجراء تغيير ما, ستكونين قادرة على القيام بهذا التغيير من خلال تعديل أقل كمية ممكنة من الشيفرة البرمجية.
صفحات السلسلة
المؤلف: Al-Farooque Shubho
المصدر: http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife
المترجم: غريب بهجت فلازي
[1]مبدا المسؤولية الوحيدة: Single Responsibility Principle
[2] Manageability
[3] Axis Of Change
[4] Coupled
[5] User Interface
[6] Software Applications
[7] Return
[8] Include
[9] Build
نقاش
Powered by Facebook Comments
Pingback: كيف شرحت التصميم الغرضيّ التوجّه لزوجتي – مبدأ (ليسكوف) في الاستبدال | مترجم - Moutarjam
Pingback: كيف شرحت التصميم الغرضيّ التوجّه لزوجتي – مبدأ (مفتوح – مغلق) | مترجم - Moutarjam