AR
RU
EN
ES
ZH
FR
DE
PT
HI
مقدمة: عندما تتوقف مبادئ SOLID عن كونها نظرية
\nمعظم المطورين على دراية باختصار SOLID على مستوى "يجب أن يكون الفصل مسؤولاً عن شيء واحد". ومع ذلك، في المشاريع الحقيقية بلغة C# (.NET) مع حقن التبعية (Dependency Injection)، والخدمات المصغرة، والأنماط غير المتزامنة، يؤدي الالتزام الساذج بالمبادئ إلى تأثير عكسي - التعقيد المفرط، وتضخم الواجهات، وانتهاك التغليف.
\nفي هذه المقالة، سننظر إلى SOLID ليس كمجموعة من العقائد، بل كأداة لاتخاذ القرارات المعمارية. ستتعلم كيفية تطبيق المبادئ بشكل صحيح في السيناريوهات المتقدمة: العمل مع حاويات IoC، والتركيب بدلاً من الوراثة، ومعالجة الأخطاء من خلال الواجهات، واختبار الساغا.
\n\n1. المسؤولية الفردية: حدود المسؤولية في DDD
\nغالباً ما يتم الخلط بين مبدأ المسؤولية الفردية (SRP) وبين "فصل واحد - وظيفة واحدة". في الواقع، يتعلق الأمر بـ سبب التغيير (reason to change). في سياق C# والتصميم القائم على المجال (Domain-Driven Design)، هذا يعني أن الفصل يجب أن يتغير فقط لسبب واحد، مرتبط بفاعل واحد أو قاعدة عمل واحدة.
\n\nالنمط المضاد المتقدم: "الكيان الإلهي"
\nلننظر إلى مثال نموذجي لانتهاك SRP في .NET - الفصل OrderEntity، الذي يدير في نفس الوقت حالة الطلب، ويحسب الضرائب، ويرسل البريد الإلكتروني، ويحفظ البيانات في قاعدة البيانات من خلال Entity Framework.
// ❌ انتهاك SRP\npublic class OrderEntity\n{\n public int Id { get; set; }\n public decimal Total { get; set; }\n public string Email { get; set; }\n\n public void CalculateTax() { /* منطق الضرائب */ }\n public void SendConfirmation() { /* إرسال البريد الإلكتروني */ }\n public void SaveToDatabase() { /* EF Core SaveChanges */ }\n}\nالمشكلة: تغيير قاعدة عمل تتعلق بالضرائب (على سبيل المثال، قانون جديد) سيؤدي إلى تغيير الفصل المسؤول أيضاً عن إرسال الإشعارات. هذا يزيد من خطر الانحدار (regression).
\n\nالحل: فصل الخدمات من خلال DI
\n// ✅ SRP من خلال الخدمات\npublic class Order\n{\n public int Id { get; set; }\n public decimal Total { get; set; }\n // الحالة فقط، لا منطق\n}\n\npublic class TaxCalculator : ITaxCalculator\n{\n public decimal Calculate(Order order) { /* ... */ }\n}\n\npublic class EmailService : INotificationService\n{\n public Task SendConfirmation(Order order) { /* ... */ }\n}\n\npublic class OrderRepository : IRepository<Order>\n{\n public Task SaveAsync(Order order) { /* EF Core */ }\n}\nالآن كل فصل لديه سبب واحد بالضبط للتغيير. حاوية DI (Microsoft.Extensions.DependencyInjection) تربطهم من خلال المنشئات (constructors).
\n\n2. مبدأ الإغلاق للفتح: التوسع من خلال الاستراتيجية والديكوراتور
\nينص مبدأ الإغلاق للفتح (OCP) على: يجب أن يكون الفصل مفتوحاً للتوسع، ولكنه مغلق للتعديل. في .NET، يتم تحقيق ذلك ليس فقط من خلال الوراثة، ولكن أيضاً من خلال التركيب مع أنماط Strategy و Decorator.
\n\nالحالة المتقدمة: التحقق مع تزايد القواعد
\nتخيل أن لديك نظاماً للتحقق من صحة الطلبات. الإصدار الأولي كان يتحقق فقط من المبلغ والعنوان. بعد شهر، تمت إضافة قاعدة "لا يمكن طلب سلع بمبلغ يتجاوز الحد الأقصى". بدلاً من تعديل الفصل OrderValidator، نستخدم التركيب.
// ❌ انتهاك OCP - تعديل الفصل الحالي\npublic class OrderValidator\n{\n public bool Validate(Order order)\n {\n if (order.Total < 0) return false;\n if (string.IsNullOrEmpty(order.Address)) return false;\n // قاعدة جديدة - نقوم بتعديل الفصل\n if (order.Total > 10000) return false;\n return true;\n }\n}\n// ✅ OCP من خلال تركيب المدققات\npublic interface IValidator<T>\n{\n bool Validate(T entity);\n}\n\npublic class TotalValidator : IValidator<Order>\n{\n public bool Validate(Order order) => order.Total > 0;\n}\n\npu 
