حذف المنتجات - حذف الصور والصور المصغرة - ضمن سلسلة بناء موقع متكامل للت...

 اهلا وسهلا بكم احبائي في الدرس الثاني من مفهوم الـ Solid Responsible وان شاء سوف نشرح لكم المقصود بالمبدأ الاول او القاعدة الاولى من هذا المفهوم وهو Single Responsibility Principle

المقصود بـ Single Responsibility Principle

وهو يأخذ حرف الـ S  من كلمة Solid  وختصارا لكلمة (ٍٍٍSRP) حيث 

S :Single

R :Responsibility

P : Principle  

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

هذا يعني اننا اذا اردنا معالجة وتطوير كود خاص بالمبيعات نذهب الى الكلاس المختص بالمبيعات .. ونفس الشئ اذا اردنا ان نعالج او نطور كود خاص بالمشتريات نذهب الى الكلاس الخاص بالمشتريات .

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

وبمعنى اخر حتى تتبع قاعدة او مبدأ Single Responsibility Principle  يجب ان تتخد كلاس معين كمجموعة لدوال تعبر عن وظيفة واحده تخص هذا الكلاس فمثلا اذا انشأنا كلاس خاص بالمشتريات Purchases يكون محتواه دوال وظيفية خاصة بالمشتريات فقط مثل دوال خاصة بـ  ( الانشاء على المشتريات  او التعديل على المشتريات او حذف صنف من المشتريات  او عرض المشتريات  او حساب المشتريات ) أي ان كل شئ خاص بالمشتريات 

دعونا نأخذ المثال التالي  .. معانا كلاس يسمى payment Processor خاصة بالدفع  وفيه الدوال  الموضحة في الصور. 

هل هذه الكلاس يحقق مبدأ SRP ؟

اختبار مبدأ SRP  على مستوى الكلاس 

من الاسباب المهمه التي لا تجعل الكود يطبق مبدأ الـ SRP  ان يكون هناك اكثر من وظيفة في الكلاس او ان يكون هناك  اكثر من سبب  . لا معي الصورة التالية 

لاحظ معي في الصورة اعلاه اننا معنا اربع دوال  وهي كتالي :

•  دالة خاصة بالشحن تسمى charge  وظيفتها تحصل على الرصيد وتحفظه بالحساب او قد تكون تحصل على بيانات البنك الخاصة بالدفع وترسل الطلب الى البنك 
• دالة خاصة بانشاء تقرير تسمى Create Report : اي تقوم بانشاء تقرير
• دالة تقوم بطباعة تقرير تسمى Print Report : اي تقوم بطباعة التقرير 
• دالة تقوم بحفظ التقرير تسمى  Save Report : اي حفظ التقرير 

الان لو قمنا بتحليل هذا الكلاس هل كل محتواه من دوال خاص بالدفع مع العلم ان الكلاس يسمى الدفع Payment 

لو لاحظنا الدالة الاولى المسمى charge  نلاحظ انها خاص بستجيل الرصيد وارسالها للبنك وهذا بالفعل خاصل بـ Payment  .. اذن الدالة الاولى تحقق مبدأ SRP .

 الدوال الباقية والخاصة بانشاء التقرير وطباعته وحفظه .. هذه الدوال يجب ان لا تكتب في هذا الكلاس الخاص بالدفع 

بل يجب ان تستدعى من كلاس خاص بالتقارير ... اذا هذه الدوال لا تحقق مبدأ SRP  في هذا الكلاس لانها ليس لها اي علاقة بالدفع في هذا الكلاس بالضبط لذلك يجب فصل كلاس التقارير عن كلاس الدفع .. واذا اردت استخدامهم في هذا الكلاس يجب استدعاؤهم من الكلاس الخاصة بالتقارير . وايضا هذا الكلاس لا يحقق مبدأ SRP  لانه احتوى على دوال مختلفة لوظائف مختلفة ولا تعبر عن اسم الكلاس الدفع .

 

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

كذلك من الشروط الذي تفقد عدم تقييد الكلاس بمبدأ SRP  هو ان يفقد مفهومه . حيث يجب ان يكون مفهومه ومسماه واضح للمبرمجين 

فمثلا اذا طلب منك التعديل على الشحن او كتابة الرصيد  هنا مباشرة سوف تذهب الى الكلاس الخاص بالدفع والذهاب الى الدالة المسمى charge ... كما نعلم ان وظيفة الشحن للرصيد لها علاقة بالدفع .. هنا هذه الدالة تحقق المبدأ وليس بها اي مشكلة 

لكن اذا طلب منك تعديل على انشاء التقارير ... وبما انك كتبت دالة انشاء التقرير في هذه الكلاس ( وهذا اصلا لايجب ان يكتب في هذا الكلاس ) سوف تتذكر ماهو الكلاس الذي عملت فيه دالة انشاء التقارير . هنا هذا الكلاس فقد مفهومه وفقد مبدأ تحقق SRP  لانه يجب كما ذكرنا ان يكون هذه الكلاس فقط للتعديل والتطوير على وظائف تخص عمليات الدفع .

اذن ماهو الحل لجعل هذا الكلاس يحقق مبدأ SRP هو انك تنقل الدوال الخاصة بانشاء التقرير وطباعة التقرير وكذلك حفظ التقرير وتجعله في كلاس خاص بالتقارير ... وتستدعي هذه الكلاس في الدالة المسمى Charge .

اختبار مبدأ SRP على مستوى الدوال 

دعونا نأخذ هذا المثال :

لاحظ معي الدالة في الصورة .. هذه دالة تقوم  بانشاء تقرير مبيعات بتستقبل رقم العميل وتعيدلك  التقرير .. لاحظ معي الخطوات التي في هذه الدالة 

• جلب بيانات العميل بالاعتماد على رقم العميل 
• جلب المبيعات باعتماد رقم العميل 
• حساب الرصيد من خلال  حساب الاجمالي ثم طرحه من الدفع 

لو حللنا هذه الدالة لنرى هل مبدأ SRP  يتحقق فيها .. الاجابة لا ! لماذا ؟

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

لناخذ مثال اخر 

نلاحظ  من الصورة اعلاه ان هذا الكلاس جمع دالتين تقومان بوظيفتان مختلفتان في نفس الكلاس وهي تسجيل الموظف وكذلك  ارسال ايميل ... وهذا لا يحقق مبدأ SRP حيث يجب فضل الدالة التي تقوم بارسال الايميل في كلاس اخر .. وهنا نكتفي باستدعاء الدالة التي تقوم بارسال الايميل من كلاس مختص بارسال الايميل . كما هو  واضح في الصورة اسفل .

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