مبادئ التصميم SOLID Design Principles

Mohammed Khalid

Mohammed Khalid

منذ 5 أشهر

6 دقائق للقراءة

1109 كلمة


مبادئ التصميم SOLID Design Principles

SOLID Design Principles مبادئ التصميم #

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

طيب SOLID Design Principles ممكن نعرفها على أنها خمس مبادئ لا سادس لها لتصميم أكواد البرمجيات بطريقة عملية وقابلة للتوسعة والتطوير وبمجهود أقل وكود نظيف Clean Code ومؤسس صح.

ملاحظة: #

المبدأ الأول: Single Responsibility Principle SRP

مبدأ SRP بيشترط علينا نحدد لكل Class مسؤولية واحدة وظيفة واحدة فقط، يعني الوزير معروف عنده مهام محددة ينجزها ويتخارج، المبدأ دا ضد الشلاقة شغلة ما شغلتك ما تمسكها، خليها لزولها البيعرف ينجضها. طيب لو عايزين نعكس كلامنا دا في البرمجة لو عندنا Class مثلاً اسمه Context مسؤول عن العمليات الـ Database يعني شكل الدوال Methods حتكون جواه كالآتي:

  • -- دالة Connect البتحقق من صحة الاتصال بقاعدة البيانات.
  • -- دالة Open البتفتح الاتصال بقاعدة البيانات.
  • -- دالة ExecuteQuery البتنفذ لينا أوامر SQL في قاعدة البيانات.
  • -- طيب نزلنا تحت لقينا دالة ConvertGregorianToHijri وظيفتها تحويل

تاريخ الميلادي للهجري وتعاين فوق 🙄 تلقاها قاعدة في كلاس خاص بعمليات قواعد البيانات، دي عاملة زي تبعية وزارة الإتصالات وتقنية المعلومات السودانية للقوات المسلحة. 😂 مبدأ SRP بيقول المفروض الدالة ConvertGregorianToHijri دي نعمل ليها كلاس تاني خاص بعمليات تحويلات التواريخ ممكن تسميها DateConverter وبالطريقة دي تعمل كلاساتك عشان يكون تطبيقك منظم ومرتب.

المبدأ الثاني: Open-Closed Principle OCP

المبدأ دا بيشترط علينا كيف نخطط كويس ونعاين لقدام أثناء بناء برمجيتنا عشان تكون أكتر مرونة في إضافة المميزات الجديدة، ولكن كمان بشدد علينا ما نهبش المميزات القديمة ونعدل فيها، طالما الكود القديم شغال خليه زي ما هو أنت ما ناقص وما داير وجع رأس من العملاء ويبدأ معاك مسلسل معالجة البقات Bugs.

طيب لو عندنا تطبيق بسيط مربوط مع قاعدة بيانات SQL Server وأمورنا طيبة، وفي المستقبل تطلب الآمر ننقل التطبيق لـ Host جديد بس ما عنده SQL Server قالو عندهم MySQL طيب دي معناها حتعدل في كودك وتحول أكواد SQL Server لأكواد MySQL معناها حتحتاج جهد كبير وحتفتح باب لدوامة بتضيع فيها مجهود وزمن في الفاضي، طيب لو اكتشفت بأنو عندهم خدمة SQL Server حتقول ما كان في داعي للتعب دا كله، أها تقعد تاني تعمل Rollback؟!

المبدأ OCP بيقول من البداية أسس تطبيقك صح أعمل كلاسات مجرد Abstract Class مثلاً سميه Database اسم عام وخت فيهو جميع العمليات البتخص قواعد البيانات، الكلاس المجرد زي كلمة "بني آدم" مخلوق يمشي على قدمين وعندو أعضاء بداخله وبيتكلم وبيفكر وبيقرأ البوست دا. طيب ننتقل للخطوة التالية نعرف كلاس جديد بإسم MySQL ونخليه يرث من Database ونخت فيهو جميع أكواد MySQL، مثلاً انتقلت لهوست بيدعم Oracle تقول ليهو حبابك، تعمل ليك كلاس جديد اسمه Oracle خليه يرث من Database وأكتب فيهو الأكواد الخاصة في أوراكل، هكذا ودواليك زي ما بيقول أ.خالد السعداني، كده لاحظنا بأنو ما هبشنا الكود القديم، كتبنا فوق ليهو كود جديد معاناها أضفنا ميزة جديدة بالإضافة أننا احتفظنا بالمزايا القديمة، وبتقدر ترجع لكودك القديم في أي وقت.

المبدأ الثالث: Lisko Substitution Principle LSP

المبدأ دا صعب إلا نشرحه بالعامية لو عندنا زول اسمه "عيسى آدم إبراهيم" معناها بالمنطق عيسى وارث من آدم وآدم وارث من إبراهيم، لمن نقول عيسى دا ولد آدم العبارة صحيحة، ولمن نقول عيسى ولد إبراهيم برضو العبارة صحيحة، لأنو أنت ود أبوك وود جدك، وجدك دا زاتو في مقام أبوك. طيب مبدأ LSP لمن نعكسه في البرمجة، بيقول لمن تشتري Corolla أنت فعلياً بتأخذ نسخة منها Object بإعتبار Corolla دا كلاس ووارث من كلاس Toyota لأنها الشركة الأم، طيب الـ Object لو اخذناهو من كلاس Corolla لكن خلينا قيمته تساوي قيمة الجد Toyota المفروض التطبيق حقك دا ما يضرب معاك ويشتغل زي الحلاوة، لأنو جدك ببساطة هو أبوك برضو.

المبدأ الرابع: Interface Segregation Principle ISP

النقطة دي محتاج تكون عندك معلومة عن OOP وتحديداً Interface، خلينا نمرق من المبدأ نوضح الـ Interface ونرجع للمبدأ تاني، طيب الـ Interface دي ممكن نقول السلطة القضائية البتضع التشريعات والقوانين بشكل عام والـ Class هو السلطة التنفيذية. طيب خلوني ابسطها ليكم أكثر طيب لو قلنا Interface مثلاً نقول جلابية يعني عبارة قماش وتفصيلة المتعارف عليها أنها جلابية، طيب الجلابية دي في النهاية لازم يكون في زول حيشتريها ويلبسها، بس الزول ياهو الـ Class زاتو.

المبدأ ISP بيقول الزول المفروض ما يشتري جلابية واحدة كاملة المميزات والمواصفات تكون شاملة للبيت والمرقة، بالمنطق كده ما محتاج لجلابية مطرزة عشان تقعد بيها في البيت، المبدأ ISP بيشترط التقسيم والتخصيص، يعني تجيب جلابية للبيت براها بمواصفات جلابية بيت على حسب احتياجك، وتجيب جلابية مخصصة للمرقة بالمواصفات الطلعات والمرقات على حسب احتياجك برضو.

طيب لو عكسنا الكلام دا في البرمجة المبدأ بيقول خلي Class يرث من Interfaces المحتاج ليها فقط أحسن يرث من 2 Interfaces صغار محتاج لجميع الـ Methods الفيها أفضل بكثير من يرث من Interface كبيرة ومليانة Methods ما محتاج ليها.

المبدأ الخامس: Dependency Inversion Principle DIP

مبدأ DIP دا بيشترط الإعتماد على القواعد العامة والمجردة في بناء البرمجيات، حتى في عملية التواصل بين الطبقات، ونحاول نقلل من استخدام الـ Class يعني بدل ما نعرف كلاس جلابية سودانية وكلاس تاني جلابية خليجية وبلا بلا بلا، نعمل Interface عامة اسمها جلابية بمواصفات الجلابية المتعارف عليها، ونخت فيها جميع مواصفات الجلابية من طول وحجم وطول الكم بشكل عام وبنستخدم الـ Interface كحلقة وصل بين طبقات برمجياتنا الدنيا Low Level والطبقات العليا High Level، بعداك بنحدد ليهو الكلاس الإفتراضي التنفيذي البيطبق قوانين وتشريعات الـ Interface في الإعدادات بنقدر نتحكم فيها زي ما عايزين في أي وقت، لو فصلت النقاط دي أكثر الشرح حيطول، أحسن نخليها في مقالات مفصلة خاص بيها في المستقبل بإذن الله.

باب المشاركات مفتوحة .

ربنا يكتب التوفيق للجميع ... دمتم في آمان الله 🌹

تابع محمد خالد علي :الفيسبوك

شارك المقال علي وسائل التواصل :


فيسبوكلينك اندتويترقيت هبالمدونة