⚡SOLID Principles ⚡
(Part 1)

ايش هي SOLID ؟! وكيف نطبقها ؟!

أولاً SOLIDهي مبادئ او قواعد ارشاديه بنمشي عليها اثناء بناء SW بحيث انها تسهل علينا فيما بعد تطبيق أي Design Patterns وحتى لو ما طبقنا Design Patterns فهذي المبادئ بحد ذاتها بتحسن من جودة SW .

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

⚡ أول مبدأ Single Responsibility Principle (SRP)

كلنا ما نحب تحمل مسؤوليات كثيره (الخارجة عن إرادتنا) لأنه بتخلي حياتنا معقدة وممكن بأي لحظة نتحول لقنبلة من أطرف سبب من كثرة الضغط 😵 نفس الشيء ينطبق على الكلاس.

عشان يكون بسيط وقابل للصيانة والتطوير لابد انه يكون مسؤول عن هدف واحد فقط كيف يعني 🤔! Uncle Bob قال:

“ there should never be more than one reason for a class to change”
يجب ألا يكون هناك أكثر من سبب يخليك تدخل للكلاس وتعدل فيه.

مثلاً لو كان عندنا كلاس PaymentProcessor لشحن الحساب وفيه عدة وظائف Methods مثل :

charge()
تستقبل المبلغ المطلوب للشحن وتعمل إجراءات الشحن.

createReport()
تنشئ تقرير عن عملية الشحن هل تمت او لا.

لو جينا نشوف كم سبب يخلينا ندخل الكلاس عشان نعدل فيه !

بنلاقي انه اول سبب هو تغير إجراءات الشحن وهذي وظيفة الكلاس مارح نختلف عليها 🙏.

ثاني سبب لو مثلاً بنغير في format التقرير! نضطر ندخل للكلاس ونغير الـ format وهذا هدف خارج عن مسؤولية الكلاس!!

اوك صح لابد من انشاء تقرير اثناء عملية شحن الحساب ولكن الكلاس غير مسؤول عن تعديل الـ implementation الخاص بأنشاء تقرير.

وعشان نحل المشكلة بيتم انشاء كلاس للتقرير ومن ثم يتم استدعاء دالة انشاء التقرير، وبكذا حققنا مبدأ SRP واصبح كُل راعٍ مسؤولٌ عن رعيته😊.

وأخيراً هذا المبدأ لا يطبق فقط على مستوى الـ Class وإنما على مستوى الـ Methods ايضاً.

.
يتبع..

بدايه مبرمج

بدايه مبرمج

Photo

⚡SOLID Principles ⚡
(Part 1)

ايش هي SOLID ؟! وكيف نطبقها ؟!

أولاً SOLIDهي مبادئ او قواعد ارشاديه بنمشي عليها اثناء بناء SW بحيث انها تسهل علينا فيما بعد تطبيق أي Design Patterns وحتى لو ما طبقنا Design Patterns فهذي المبادئ بحد ذاتها بتحسن من جودة SW .

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

⚡ أول مبدأ Single Responsibility Principle (SRP)

كلنا ما نحب تحمل مسؤوليات كثيره (الخارجة عن إرادتنا) لأنه بتخلي حياتنا معقدة وممكن بأي لحظة نتحول لقنبلة من أطرف سبب من كثرة الضغط 😵 نفس الشيء ينطبق على الكلاس.

عشان يكون بسيط وقابل للصيانة والتطوير لابد انه يكون مسؤول عن هدف واحد فقط كيف يعني 🤔! Uncle Bob قال:

“ there should never be more than one reason for a class to change”
يجب ألا يكون هناك أكثر من سبب يخليك تدخل للكلاس وتعدل فيه.

مثلاً لو كان عندنا كلاس PaymentProcessor لشحن الحساب وفيه عدة وظائف Methods مثل :

charge()
تستقبل المبلغ المطلوب للشحن وتعمل إجراءات الشحن.

createReport()
تنشئ تقرير عن عملية الشحن هل تمت او لا.

لو جينا نشوف كم سبب يخلينا ندخل الكلاس عشان نعدل فيه !

بنلاقي انه اول سبب هو تغير إجراءات الشحن وهذي وظيفة الكلاس مارح نختلف عليها 🙏.

ثاني سبب لو مثلاً بنغير في format التقرير! نضطر ندخل للكلاس ونغير الـ format وهذا هدف خارج عن مسؤولية الكلاس!!

اوك صح لابد من انشاء تقرير اثناء عملية شحن الحساب ولكن الكلاس غير مسؤول عن تعديل الـ implementation الخاص بأنشاء تقرير.

وعشان نحل المشكلة بيتم انشاء كلاس للتقرير ومن ثم يتم استدعاء دالة انشاء التقرير، وبكذا حققنا مبدأ SRP واصبح كُل راعٍ مسؤولٌ عن رعيته😊.

وأخيراً هذا المبدأ لا يطبق فقط على مستوى الـ Class وإنما على مستوى الـ Methods ايضاً.

.
يتبع..

hottg.com/beginprogrammer/632

1.5K viewsOct 17, 2021 at 17:39