في عالم تطوير البرمجيات، تخبرنا مبادئ SOLID بكيفية تنظيم الوظائف والبيانات بحيث تكون رموزنا:

• تحمل التغييرات
• كن سهل الفهم
• كن الأساس للمكونات التي يمكن استخدامها في العديد من الأنظمة البرمجية

مصطلح SOLID هو اختصار لخمس مسلمات تصميمية، كما هو موضح أدناه:

(S) مبدأ المسؤولية الفردية: "يجب أن تحتوي الوحدة على سبب واحد فقط للتغيير"
(O) مبدأ مفتوح/مغلق: "يجب أن تكون قطعة البرنامج مفتوحة للتوسيع ولكنها مغلقة للتعديل"
(L) مبدأ استبدال ليسكوف: "يجب استبدال الفئة المشتقة بفئتها الأساسية"
(I) مبدأ فصل الواجهة: "لا ينبغي إجبار الفصل على تنفيذ واجهات وأساليب لن يستخدمها"
(د) مبدأ انعكاس التبعية: "تعتمد على التجريدات وليس التطبيقات"

الصلبة وجولانج

تم تصميم SOLID للبرمجة الشيئية، ومن المعروف أن GoLang ليست لغة تتبنى هذا النموذج. ومع ذلك، يمكننا استخدام الموارد التي توفرها لتلبية منهجية OOP. على سبيل المثال، لا تتمتع Go بدعم الميراث، ولكن يمكن تعويض الفكرة بدعم تكوينها. وبالمثل، يمكن إنشاء نوع من تعدد الأشكال باستخدام الواجهات.

في هذه المقالة، الأولى في سلسلة من 5 مقالات، أنوي تفصيل المبدأ الأول بأمثلة قريبة من المواقف التي نواجهها يوميًا.

مبدأ المسؤولية الفردية (SRP)

نحن نعرف بالفعل ما يعنيه هذا المصطلح، والآن حان الوقت لمعرفة كيفية تنفيذه في GoLang.
في هذه اللغة، يمكننا تعريف هذا المبدأ بأنه "يجب أن يكون للوظيفة أو النوع وظيفة واحدة فقط، ومسؤولية واحدة فقط"، لنرى الكود التالي:

أعلاه، لدينا بنية نسميها userService. وله خاصيتين: db وهي المسؤولة عن الاتصال بقاعدة بيانات علائقية، وamqpChannel، والتي تتيح الاتصال بخدمة مراسلة RabbitMQ.

تطبق خدمة المستخدم طريقة تسمى الإنشاء. ضمن هذه الطريقة نقوم بتخزين معلومات المستخدم المستلمة في قاعدة البيانات ومن ثم نشر البيانات إلى RabbitMQ.
يمكن ملاحظة أن مسؤولية طريقة الإنشاء في خدمة المستخدم ليست مسؤولية واحدة فقط، بل اثنتين: تخزين المعلومات في قاعدة البيانات ونشر رسالة في قائمة انتظار RabbitMQ.

قد يؤدي ذلك إلى عدة مشاكل، مثل:

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

في الكود التالي، قمنا بتعديل البنية لاحترام SRP. تحقق من ذلك:

لاحظ أننا قمنا بفصل المسؤوليات إلى ثلاثة أجزاء متميزة: المستودع UserRepository لاستمرار المستخدم في قاعدة البيانات، والناشر UserPublisher لإرسال رسالة إلى RabbitMQ، و خدمة UserService التي تنظم هاتين العمليتين.

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

من الجدير بالذكر أن هناك فرقًا دقيقًا بين أداء مهمتين مختلفتين وتفويض تنفيذهما. في المثال الأصلي لـ userService.Create، تم تنفيذ عمليتين في مكان واحد، مما ينتهك مبدأ المسؤولية الفردية. بعد إعادة البناء، قمنا بتفويض عمليات التنفيذ إلى بنيات مختلفة وكانت طريقة الإنشاء مسؤولة فقط عن تنسيق هذا التدفق.

لتطبيق SRP في هذا المثال، انتهى بنا الأمر أيضًا إلى تنفيذ بعض مبادئ SOLID الأخرى:

• مبدأ فصل الواجهة (ISP): تمثل كل واجهة مسؤولية واحدة. كل من UserRepository وUserPublisher عبارة عن واجهات لها أسلوب واحد فقط، يمثل كل منهما مسؤولية واحدة.
مبدأ انعكاس التبعية (DIP)
• : تعتمد بنية userService على التجريدات (الواجهات) وليس على تطبيقات ملموسة، أي أنها لا تعرف التنفيذ المحدد لـ UserRepository وUserPublisher، فقط الواجهات التي يقومون بتنفيذها. مبدأ
المبدأ المفتوح/المغلق (OCP)
• : الكود مفتوح للتوسيع، حيث يمكن إضافة مستودعات أو ناشرين جدد بسهولة دون تعديل خدمة المستخدم.
وفي المقالات القادمة في هذه السلسلة سأقدم شرحًا أكثر تفصيلاً لكل منها، مع أمثلة محددة.

أراكم لاحقًا يا رفاق!

مراجع:

مدونة Clean Coder - مبدأ المسؤولية الفردية