بدايه مبرمج

بدايه مبرمج

Photo

⚡SOLID Principles ⚡
(Part 2)

‏⚡ ثاني مبدأ(OCP) Open Closed Principle

- should be open for extension, but closed for modification

- جميع مكونات تطبيقك من ال Classes او Methods يجب ان تكون مفتوحة للتوسعة وإضافة مميزات جديدة لكنها مغلقة امام التعديل .

‏مثلاً لو كان عندنا كلاس Employee وفيه method لحساب الراتب بعدد الساعات لأي موظف أي تستقبل عدد الساعات فقط،

واردنا فيما بعد تطوير الكلاس بحيث تكون method تحسب الراتب بعدد الساعات حسب نوع الموظف، فهنا نضطر نعدل في الكلاس ونخلي الدالة تستقبل عدد الساعات ونوع الموظف صح !

‏خلينا نتخيل السيناريو الي ممكن يصير بسبب التعديل 🤔

لنفترض انه عندنا client يستخدم الكلاس وأستدعى الدالة (واقصد بالـ client هنا أي جزء في البرنامج ) ، اكيد بيصير له Errors صح! .

‏لأنه الدالة أصبحت تستقبل متغيرين وليس متغير، فلو كان عندنا SW كبير متخيلين كمية التعديلات اللي بنسويها بسبب التعديل ! هذا غير امور الـ testing 😵.

‏لو طبقنا مبدأ OCP من البداية كُنا وفرنا وقت وجهد.

كيف 🤔!!

نرجع نتخيل السيناريو من البداية مع تطبيق مبدأ OCP

عندنا طريقتين تٌستخدم لتنفيذ المبدأ، إما Interface أو Abstract.

‏اولاً بنغير كلاس Employee لـ Interface بحيث تكون الدالة abstract وبعدها ننشئ كلاس للمدير وكلاس للموظف العادي ويورثوا من Interface وكل كلاس يعمل implementation للدالة بحسب احتياجه،

‏بحيث عندما تُستخدم الدالة من أي client سيتم انشاء obj من الكلاس المُراد سواءً مدير او موظف ومن ثم يتم استدعاء الدالة.

طيب ايش استفدنا 🙄!

‏لو في ما بعد حبيت تطور الكود وتخليه يحسب الراتب لنوع اخر من الموظفين، اللي عليك تنشئ كلاس لهذا الموظف ويورث كلاس Employee

أو مثلاً حبيت تضيف دالة لحساب الراتب الشهري بتضيفها طيبيعي في Interface وبعدها تستخدمها لأي كلاس.

وبكذا مارح نضطر إلى التعديل في كلاس Employee و تجنبنا اضرار التعديلات واصبح كلاس Employee قابل للإضافات ولكن مُغلق لأي تعديل.

‏أخيراً متى يُستخدم هذا المبدأ! إذا شفنا انه الكلاس قد يكون فيه عمليات متغيرة وليست ثابته. 🙏🏼

يتبع...

www.tgoop.com/beginprogrammer/633

1.7K viewsOct 19, 2021 at 17:21

⚡SOLID Principles ⚡
(Part 2)

‏⚡ ثاني مبدأ(OCP) Open Closed Principle

- should be open for extension, but closed for modification

- جميع مكونات تطبيقك من ال Classes او Methods يجب ان تكون مفتوحة للتوسعة وإضافة مميزات جديدة لكنها مغلقة امام التعديل .

‏مثلاً لو كان عندنا كلاس Employee وفيه method لحساب الراتب بعدد الساعات لأي موظف أي تستقبل عدد الساعات فقط،

واردنا فيما بعد تطوير الكلاس بحيث تكون method تحسب الراتب بعدد الساعات حسب نوع الموظف، فهنا نضطر نعدل في الكلاس ونخلي الدالة تستقبل عدد الساعات ونوع الموظف صح !

‏خلينا نتخيل السيناريو الي ممكن يصير بسبب التعديل 🤔

لنفترض انه عندنا client يستخدم الكلاس وأستدعى الدالة (واقصد بالـ client هنا أي جزء في البرنامج ) ، اكيد بيصير له Errors صح! .

‏لأنه الدالة أصبحت تستقبل متغيرين وليس متغير، فلو كان عندنا SW كبير متخيلين كمية التعديلات اللي بنسويها بسبب التعديل ! هذا غير امور الـ testing 😵.

‏لو طبقنا مبدأ OCP من البداية كُنا وفرنا وقت وجهد.

كيف 🤔!!

نرجع نتخيل السيناريو من البداية مع تطبيق مبدأ OCP

عندنا طريقتين تٌستخدم لتنفيذ المبدأ، إما Interface أو Abstract.

‏اولاً بنغير كلاس Employee لـ Interface بحيث تكون الدالة abstract وبعدها ننشئ كلاس للمدير وكلاس للموظف العادي ويورثوا من Interface وكل كلاس يعمل implementation للدالة بحسب احتياجه،

‏بحيث عندما تُستخدم الدالة من أي client سيتم انشاء obj من الكلاس المُراد سواءً مدير او موظف ومن ثم يتم استدعاء الدالة.

طيب ايش استفدنا 🙄!

‏لو في ما بعد حبيت تطور الكود وتخليه يحسب الراتب لنوع اخر من الموظفين، اللي عليك تنشئ كلاس لهذا الموظف ويورث كلاس Employee

أو مثلاً حبيت تضيف دالة لحساب الراتب الشهري بتضيفها طيبيعي في Interface وبعدها تستخدمها لأي كلاس.

وبكذا مارح نضطر إلى التعديل في كلاس Employee و تجنبنا اضرار التعديلات واصبح كلاس Employee قابل للإضافات ولكن مُغلق لأي تعديل.

‏أخيراً متى يُستخدم هذا المبدأ! إذا شفنا انه الكلاس قد يكون فيه عمليات متغيرة وليست ثابته. 🙏🏼

يتبع...

BY بدايه مبرمج