ماهية الـ Design Principles – الجزء 1 من 2

مُقدمة:

سأكتب بإختصار عن ال Design Patterns الأكثر شيوعا و التي ستجعلك تعشق الشفرات البرمجية Code الخاص بك، و لا تخف منه و لا يصير "شخشوخة ?" في نظرك عندما يصبح حجمه مليون ? سطر.

قبل أن نبدأ☝️..

ماهي ال Design Principles و ماهي علاقتها بـ Design Patterns ؟

الـ Design Pattern هو الحل المشترك لمشكل يتكرر في حالة معينة/معطاة. الـ Design Principle هو عادة برمجية تكررها أو مبدأ تمشي عليه أثناء كتابة ال Code.

و هاتين الفكرتين تضمنان لك أحد معايير جودة البرامج و هي الـ Maintainability أو ما يعرف بـ قابلية صيانة/تعديل البرامج مستقبلا. و ليكن في علمك، أنه إذا كنت ستمضي 6 أشهر في تعلم لغة برمجة أو تقنية ما، فإنك ستكمل باقي حياتك في تعديل الـ Code و صيانته، تدريجيا مع الوقت، و التي تُظهر الجانب الفني إن صح التعبير لك كـ مُطور و هذا من بين الأشياء التي لن تتعلمها في الكتب أو الدورات بل من الخبرة. 

من بين الأشخاص الذين تحدثوا في الـ Maintainability هو " مارتن فلاور – Martin Flower " يمكنك مُتابعة مُدونته على الرابط التالي martinfowler.com و التي ينشر فيها من حين إلى أخر بعض المقالات عن موضوع الصيانة هذا.

ملاحظة  : سوف أستخدم كلمة عنصر/عناصر component(s) عدة مرات و سيختلف معناها بحسب مستوى التفصيل و/أو سياق الكلام الذي نكون فيه، فقد أقصد بها function او class او module...الخ.

نكمل، و سيكون الهدف كالتالي : 

1. تقليل الإعتماد بين العناصر minimizing coupling لكل عنصر مع الأخر.
2. زيادة التماسك maximizing cohesion بين العناصر و جعل إرتباطها وثيقا. 

نبدأ : 

1. DRY - Don’t Repeat Yourself

ترجمتها "لا تكرر نفسك"، إذا وجدت نفسك تكرر الكود copy-paste كثيرا فـ على الأرجح أنك تجاوزت/إنتهكت هذه القاعدة، و إذا تكرر منطق البرنامج فقد حان الوقت للتفكير في Refactorisation و جعل الكود المكرر في عنصر وحده و استدعيه متى إحتجته.

أما في حالة عندك نفس الكود مكرر مرتين مثلا و لكن يحل أو يفعل شيئين مُختلفين، فـ لا بأس من تركه لأن له وظيفتين مُختلفتين، في هذه الحالة إذا جمعتهما في عنصر واحد، فقد يتغير ال Specifications notebook فتُظطر مع الوقت إلى التغيير اليدوي للكود و الإستعمال الزائد للجمل الشرطية if-else

في المقال القادم نُكمل و نتحدث عن:

1. DRY - Don’t Repeat Yourself
2. Encapsulate What Changes
3. Open Closed Design Principle
4. Single Responsibility Principle (SRP)
5. Dependency Injection (DI) principle :
6. Favor Composition over Inheritance
7. Liskov Substitution Principle (LSP)
8. Interface Segregation Principle (ISP)
9. Programming for Interface not implementation
10. Delegation Principles

شكرا لكل من:

الكاتب الأصلي: Younes Chaoui
ترجمة: Moamet Ameed

أنت أيضا إذا كان بوِدِك الإنضمام إلى فريق التحرير أو لديك موضوع للإقتراح، إتصل بي أو ألق نظرة على صفحة دعم المُبادرة.