تطبيق واقعي لمفاهيم 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

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

[٧‏/٧، ٧:٢٢ ص] أ. انور السياري IT: # Feature Specification: Tenant Relationship Lifecycle

Feature Branch: [001-tenant-relationship-lifecycle]

Created: 2026-07-07

Status: Draft

Input: User description: "Rebuild and improve the TenantRelationship stored procedure family so it supports invitation, approval, rejection, suspension, reactivation, soft deletion, restoration, status updates, permission updates, role updates, service updates, validation, account creation, and consistent result contracts without creating new tables."

## User Scenarios & Testing *(mandatory)*

User stories are written as independently testable database and business workflows. Each story must be verified with tenant-scoped SQL examples that prove the resulting relationship row, related service/permission rows, related account row, audit log, rollback behavior, and structured result payload.

### User Story 1 - Invite User Into Tenant Relationship (Priority: P1)

A tenant owner or authorized administrator invites an existing user to establish a specific tenant relationship type, such as customer, supplier, accountant, sales employee, purchase employee, bank/cash, or deposit customer. The invitation records the tenant, invited user, relationship type, intended account parent from the relationship type, requested services, requested permissions, requested roles, and invitation metadata without activating access before approval.

Why this priority: Invitation is the entry point for every later lifecycle step. Duplicate or unauthorized invitations create financial-account ambiguity and permission leakage.

Independent Test: Execute the rebuilt invitation procedure with an authorized creator, active tenant, active device, active relation type, and optional services/permissions/roles payload; assert exactly one pending relationship row exists for (tenantId, userId, typeId), no active access is granted yet, a tenant log exists, and the result includes a success code, message, and relationship key.

Acceptance Scenarios:

1. Given an active tenant, an active invited user, an active creator relationship allowed to invite, and an active relationship type, When the invitation procedure runs, Then a pending tenant relationship is created once, related requested service/permission/role metadata is staged consistently, and the response identifies the relationship.
2. Given an existing active, pending, suspended, disabled, rejected, or deleted relationship for the same tenant, user, and relationship type, When a duplicate invitation is attempted, Then the operation returns a structured conflict error and leaves all relationship, service, permission, role, account, and log state unchanged.
3. Given a creator without the required tenant relationship or permission, When the invitation procedure runs, Then the operation returns a structured permission error and no rows are written.

---

### User Story 2 - Approve Invitation And Create Financial Account (Priority: P1)

The invited user, or a tenant owner/authorized administrator acting on behalf of that user, approves a pending invitation. Approval activates the relationship and creates or reuses the proper tenant financial account for the invited user under the tenant chart of accounts based on the relationship type.

Why this priority: Relationship approval grants access and connects the user to tenant financial accounting. Account creation must be idempotent to prevent duplicate customer, supplier, employee, or bank accounts.

Independent Test: Approve a pending relationship twice under controlled data. The first approval activates the relationship and creates or links one tenant account with relatedUserId and the relationship type's account parent. The second approval returns the existing activated relationship and account or a clear already-approved result, without creating a duplicate account.

Acceptance Scenarios: