تطبيق واقعي لمفاهيم abstraction and polymorphism

تعال اذكرك بشيء انت سبق لك التعامل معه،
المجلدات
والملفات: ملفات نصية، ورد، اكسل وغيرها..

وطبعا تقدر تسوي للمجلد:
انشاء
حذف
تسمية
نقل
نسخ
عرض التفاصيل،

وكذلك اي ملف تقدر تسوي له:
انشاء
حذف
تسمية
نقل
نسخ
عرض التفاصيل،

لكن لو تركز معي، هل الطريقة مختلفة اللي تسوي به حذف لملف وحذف لمجلد؟ طبعا لا ولا يوجد اي اختلاف اتعامل معهم بنفس الطريقة وليس بطريقة مختلفة... هذا هو جوهر الabstraction

طيب لو جينا الان نشتي نطبق التجريد، بالبرمجة الكائنية معانا الpolymorphism
طيب ليش تعدد الاشكال؟ بقلك التجريد يقول اتعامل مع اشياء تنتمي لنفس العائلة بنفس الطريقة..

لكن لو قلت لك لمن تضغط حذف لمجلد، هل هي نفس الخطوات اللي لو كان الحذف على ملف؟ اكيد مختلف،
وبما انه مختلف السلوك، ومشترك بالهدف، فاختلاف السلوك يخلينا بحاجه لpolymorphism بحيث كل كائن يعيد ويطبق السلوك الذي يتناسب معه....

تمرين:
اذهب الى ويندوز واضغط خصائص على مجلد، او ملف اي ملف، ستجد ان فيه عمليات مشتركة:
فتح
حذف
اعادة تسميه
نقل
نسخ
عرض التفاصيل
انشاء ملف او مجلد ،

المطلوب تصميم كلاس اب، يورث لكلاس مجلد، وكلاس ملف،بحيث يحتوي على الدوال المشتركة، ويتم عمل لها overriding حسب الكلاس الابن..

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

فرصة ذهبية متاحة للتقديم على موقع Yemen HR

https://yemenhr.com/jobs/backend-developer-qasemi-islamic-bank-sanaa-8b770764


مشاركة طيبة من الأخ والزميل أسامة الأسد بارك الله فيه🖤✨

التحليل من تحلل الشيء إذا تفسَّخت أجزاؤُه وانفصلت عناصرُه بعضُها عن بعض، وهذا الفصل مهم لأنه يصعب فهم الشيء أو المشكلة دفعة واحدة (والبرنامج كلما كبر زاد تعقيده حتى يستحيل على العقل أن يتصوره في ذهنه كاملا)، وعليك رد الشيء إلى عناصره ثم البحث في العلائق الرابطة بين هذه الأجزاء حتى تكون الصورة واضحة

وهو مهم لأن الحكم على الشيء فرع من تصوره كما يقول المناطقة، وقبل حل المشكلة عليك فهمها، فلا يعقل أن تبرمج للعميل برنامجاً لا تفهمه، فالتحليل هو الباب للفهم، والفهم أول الخطوات لحل المشكلة، وفهم المشكلة هي أول خطوة وضعها عالم الرياضيات جورج بوليا في كتابه How to Solve it

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

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

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

رحلة تامل قوة الOOP


كان لدي مشكلة مع تكرار كتابة الحقول في كل اغلب الكيانات والكود يتكرر وقواعد تحقق كثيرة

created at
created by
updated at
updated by
is edited
deleted at
deleted by
is deleted
activated at
activated by
deactivate at
deactivate by
approved at
approved by
rejected at
rejected by
rejectiion Reason



فكرت بالامر، قلت لماذا لا نسوي لهم كلاس ونورث لغيره منهم؟
اجبت حسنا، لكن ماذا لو الكلاس لا يحتاج كلهم؟ بل بعض منهما؟
السؤال الثاني ماذا لوكان الكيان هذا ينتمي لعائلة اي كلاس اب لا يمكن توريث الكلاس من ابوين...

قلت هل ثمة شيء درسته واقدر استفيد منه؟
تذكرت مبدا الinterface segregation حيث ذهبت وقسمتهما الى واجهات مستقله :
ICreatable
IUpdatable
IDeletable
IActivable
IApprovable
IRejectable

ثم اقوم بعمل كلاسات مجردة، تطبق هذا وتورث له والمطور  يقوم باختيار الذي يناسبه..

لكن واجهتني مشكلة مع المعرفات ID  بعضهما يستخدم رقم والاخر guid 
قلت لنفسي ما الذي يمكنك من تحديد النوع لاحقا؟ 
الgenerics  فكان لها قوة حقيقية مع ال interface

ما انصحك معاك https://contabo.com/en/storage-vps/?utm_source=google&utm_medium=cpc&utm_campaign=core-vps-row-en-usd&utm_term=vps&utm_content=&gad_source=1&gad_campaignid=22553456586&gbraid=0AAAAAD_Qy-f3O-o1nQlT5A6FMtEOOiAh-&gclid=Cj0KCQjwjb3SBhDgARIsAMKiWzgR4mj6fbk9qjaA4ti_WNqkZ5JVnh8bYDk_ICWR0D9_8FLAFGoRaL4aAhooEALw_wcB

شوفاهم حاجة انك تعمل السيرفر في منطقة قريبة مثل سنغافور ، اليابان ، الصين

على شان لا تتعب وانت في ال cmd

انا اشتريت واحدة في امريكا خلي على ربك بعض الاحين زمن الاستجابة بيتاخر لوما تضبح