Learn SOLID Principles in Arabic

هنتكلم عن الـ SOLID principles وهنشوف إزاي المبادئ دي بتساعدنا نحسن جودة الـ software application اللي بنبنيه. الـ SOLID principles بتوفرلنا شوية قواعد بتخلي الـ software بتاعنا:

الـ robust: يعني قوي ومتين.
الـ maintainable: يعني سهل نعدل فيه ونصلحه.
الـ reusable: يعني نقدر نستخدم أجزاء منه تاني في مشاريع تانية.

الـ SOLID Principles دي عبارة عن خمس مبادئ أساسية، وكل حرف في كلمة SOLID بيرمز لمبدأ منهم. يلا بينا نشوف المبادئ دي واحدة واحدة وبأمثلة عملية.

1. Single Responsibility Principle - SRP

حرف S في SOLID بيرمز للـ Single Responsibility Principle أو مبدأ المسؤولية الواحدة.

يعني إيه `Single Responsibility`؟

ببساطة، الـ principle ده بيقول إن: “الـ class المفروض يكون ليها سبب واحد بس للتغيير.”

يعني إيه الكلام ده؟ يعني مينفعش يكون عندك Class واحدة بتعمل أكتر من حاجة في نفس الوقت. مش محتاجين multi-tasking هنا. لو الـ class بتعمل أكتر من حاجة، هيجيلك وقت لو حاجة منهم باظت أو حبيت تعدلها، هتضطر تعدل في الـ class كلها، وده ممكن يبوظ حاجات تانية معتمدة عليها جوه نفس الـ class لو فيه complex logic بيربطهم.

الخلاصة: لازم نفصل المسؤوليات. كل class تكون مسؤولة عن حاجة واحدة بس، وبالتالي يكون ليها سبب واحد بس يخلينا نغير فيها. “لا للمالتي تاسكينج في الأوبجكت أورينتد سوفت وير”.
نفس المفهوم للـ functions: لو عندك Function بتعمل أكتر من حاجة، حاول تقسمها لـ functions أصغر، كل واحدة بتعمل مهمة محددة. ماينفعش مثلاً function تضيف user وفي نفس الوقت تبعتله notification أو email. لأ، فصل إرسال الـ email في function لوحدها، وخلي الـ function بتاعة إضافة الـ user مخصصة لإضافة الـ users وبس.

مثال: خدمة الإيميلات (`EmailingService`)

تخيل عندنا EmailingService بتعمل الآتي:

الـ SendEmail(): بتبعت إيميل (ممكن يكون فيها الـ logic بتاع الـ SMTP server).
الـ LoadEmailTemplate(): بتحمل شكل الإيميل (الـ template).
الـ UpdateEmailTemplate(): بتعدل في الـ template.

الكود قبل تطبيق SRP (مثال سيء):

// Assume this class does too much
public class EmailingServiceBeforeSRP
{
    public void SendEmail(string recipient, string subject, string body)
    {
        // Logic to configure SMTP and send email
        Console.WriteLine($"C#: Email sent to {recipient} with subject: {subject}.");
    }
 
    public string LoadEmailTemplate(string templateName)
    {
        // Logic to load template from file or DB
        Console.WriteLine($"C#: Loading template: {templateName}.");
        return $"Template content for {templateName}";
    }
 
    public void UpdateEmailTemplate(string templateName, string newContent)
    {
        // Logic to update template
        Console.WriteLine($"C#: Updating template: {templateName}.");
    }
}

المشكلة هنا إيه؟ الـ EmailingServiceBeforeSRP دي بتعمل أكتر من حاجة:

لو عايز أغير في طريقة إرسال الإيميلات (الـ SMTP configuration)، هعدل في الـ class دي.
لو عايز أغير في شكل الإيميل (الـ template، سواء كان plain text أو HTML rendered template زي الـ newsletter)، برضه هعدل في نفس الـ class.

كده مبقاش فيه “سبب واحد للتغيير”، بقى فيه أكتر من سبب. ده بنسميه violation للمبدأ.

الحل إيه؟ نفصل كل حاجة لوحدها:

الـ EmailSender: هو class مسؤولة بس عن إرسال الإيميلات (فيها الـ SMTP logic).

// Responsible only for sending emails
public class EmailSender
{
	public void SendEmail(string recipient, string subject, string body)
	{
		// SMTP logic to send email
		Console.WriteLine($"C#: EmailSender - Email sent to {recipient} with subject: {subject}.");
	}
}

الـ EmailTemplateManager: هو class مسؤولة عن تحميل وتعديل الـ templates.

// Responsible only for template management
public class EmailTemplateManager
{
	public string LoadEmailTemplate(string templateName)
	{
		// Logic to load template
		Console.WriteLine($"C#: EmailTemplateManager - Loading template: {templateName}.");
		return $"Template content for {templateName}";
	}
 
	public void UpdateEmailTemplate(string templateName, string newContent)
	{
		// Logic to update template
		Console.WriteLine($"C#: EmailTemplateManager - Updating template: {templateName}.");
	}
}

الفايدة من كده إيه؟

الـ classes بقت أصغر وأسهل في الفهم والقراءة (more readable).
بقت أسهل في إعادة الاستخدام (reusability). يعني ممكن أستخدم EmailSender لوحده من غير ما أكون مربوط بالـ template management.

مثال عملي: `OrderManager`

لتوضيح الفكرة، هنفترض وجود الكلاسات البسيطة دي:

public class Order // Helper class for the example
{
    public int OrderId { get; set; }
    public decimal TotalAmount { get; set; }
    // Other order properties...
}
 
public class PaymentDetails // Helper class for the example
{
    public string PaymentMethod { get; set; } // e.g., "Visa", "Mastercard"
    // Other payment details...
}

تخيل عندنا class اسمها OrderManagerBeforeSRP بتعمل الآتي:

الـ ProcessOrder(Order order): بتعالج الطلب.
الـ ProcessPayment(Order order, PaymentDetails details): بتعالج عملية الدفع.
الـ SendEmailNotification(Order order, String message): بتبعت إيميل تأكيد.

الكود قبل تطبيق الـ SRP (مثال سيء):

public class OrderManagerBeforeSRP
{
    public void ProcessOrder(Order order)
    {
        Console.WriteLine($"C#: OrderManagerBeforeSRP - Processing order: {order.OrderId}.");
        // Complex order processing logic
    }
 
    public void ProcessPayment(Order order, PaymentDetails details)
    {
        Console.WriteLine($"C#: OrderManagerBeforeSRP - Processing payment for order {order.OrderId} via {details.PaymentMethod}.");
        // Payment gateway integration, validation, etc.
    }
 
    public void SendEmailNotification(Order order, string message)
    {
        Console.WriteLine($"C#: OrderManagerBeforeSRP - Sending email for order {order.OrderId}: {message}.");
        // Email sending logic
    }
}

المشكلة: الـ OrderManagerBeforeSRP ده بيعمل تلات حاجات مختلفة، وده violation للـ SRP. لو حصل تغيير في نظام الـ notifications، أو في طريقة الدفع، أو في طريقة معالجة الطلبات، كل مرة هنيجي نعدل في نفس الـ class.

الحل (تطبيق الـ SRP):

الـ OrderProcessingService: مسؤولة عن معالجة الطلبات فقط.

// Handles only order processing logic
public class OrderProcessingService
{
	public void ProcessOrder(Order order)
	{
		Console.WriteLine($"C#: OrderProcessingService - Processing order: {order.OrderId}.");
		// Complex order processing logic
	}
}

الـ PaymentProcessingService: مسؤولة عن معالجة الدفع فقط.

// Handles only payment processing
public class PaymentProcessingService // Renamed from PaymentService for clarity
{
	public void ProcessPayment(Order order, PaymentDetails details)
	{
		Console.WriteLine($"C#: PaymentProcessingService - Processing payment for order {order.OrderId} via {details.PaymentMethod}.");
		// Payment gateway integration, validation, etc.
	}
}

الـ NotificationSendingService: مسؤولة عن إرسال الإشعارات فقط.

// Handles only notifications
public class NotificationSendingService // Renamed from NotificationService for clarity
{
	public void SendEmailNotification(Order order, string message)
	{
		Console.WriteLine($"C#: NotificationSendingService - Sending email for order {order.OrderId}: {message}.");
		// Email sending logic
	}
}

بكده، كل class بقت مسؤولة عن حاجة واحدة بس، ويكون ليها سبب واحد للتغيير:

الـ NotificationSendingService: أي تغيير في نظام الإشعارات هيتم هنا. نقدر نستخدمها في أي حتة في الـ application.
الـ PaymentProcessingService: أي تعديل في طرق الدفع هيتم هنا.
الـ OrderProcessingService: أي تعديل في طريقة معالجة الطلبات هيتم هنا.

وده هو الـ Single Responsibility Principle.

2. Open-Closed Principle - OCP

حرف O في SOLID بيرمز للـ Open/Closed Principle.

يعني إيه `Open/Closed`؟

المبدأ ده بيقول إن: “الـ software entities (زي الـ classes, modules, functions) المفروض تكون مفتوحة للتوسيع (open for extension)، لكن مقفولة عن التعديل (closed for modification).”

يعني إيه الكلام ده؟ يعني لو عندك Function أو Class بتعمل حاجة معينة، وعايز تزود عليها functionality جديدة، المفروض تقدر تعمل ده من غير ما تعدل سطر كود واحد في الـ source code الأصلي بتاعها. ده مهم جداً لو بتتعامل مع legacy code خايف تعدل فيه فيبوظ حاجة شغالة في الـ production. الأنتيتي بتاعت السوفتوير تكون بتسمحلك تطور وتزود فيها من غير ما تغير حاجة موجودة في الـ source code.

مثال: حاسبة الخصومات (`DiscountCalculator`)

لتوضيح الفكرة، هنفترض وجود الكلاس ده:

public class Product // Helper class
{
    public string Type { get; set; } // e.g., "electronics", "clothing", "books"
    public decimal Price { get; set; }
}

تخيل عندنا DiscountCalculator في e-commerce application:

الكود قبل تطبيق OCP (مثال سيء):

public class DiscountCalculatorBeforeOCP
{
    public decimal CalculateDiscount(Product product)
    {
        decimal discount = 0;
        // This is often done with a switch statement as well, which is also a violation
        if (product.Type == "electronics")
        {
            discount = product.Price * 0.10m; // 10% for electronics
        }
        else if (product.Type == "clothing")
        {
            discount = product.Price * 0.20m; // 20% for clothing
        }
        else if (product.Type == "books")
        {
            discount = product.Price * 0.15m; // 15% for books
        }
        // If we add a new Product type (e.g., "homeappliances"), we MUST modify this class
        return discount;
    }
}

الـ class دي بسيطة وبتحقق الـ SRP (مسؤوليتها حساب الخصم بس).

المشكلة: الـ class دي بتخالف الـ OCP. ليه؟ لأن لو حبينا نضيف نوع منتج جديد بخَصم جديد (مثلاً، أدوات منزلية)، هنضطر نعدل في الـ CalculateDiscount ونزود if-else جديدة (أو case جديدة في الـswitch). كده إحنا “عدلنا” في الكود الأصلي.

الحل (تطبيق الـ OCP باستخدام Strategy Pattern):

نعمل interface للـ discount strategy:

public interface IDiscountStrategy
{
	decimal CalculateDiscount(Product product);
}

نعمل Concrete Class لكل نوع خصم:

public class ElectronicsDiscountStrategy : IDiscountStrategy
{
	public decimal CalculateDiscount(Product product)
	{
		return product.Price * 0.10m; // 10%
	}
}
 
public class ClothingDiscountStrategy : IDiscountStrategy
{
	public decimal CalculateDiscount(Product product)
	{
		return product.Price * 0.20m; // 20%
	}
}
 
public class BooksDiscountStrategy : IDiscountStrategy
{
	public decimal CalculateDiscount(Product product)
	{
		return product.Price * 0.15m; // 15%
	}
}
 
// To extend (open for extension): add a new strategy class for a new product type
public class HomeAppliancesDiscountStrategy : IDiscountStrategy
{
	public decimal CalculateDiscount(Product product)
	{
		return product.Price * 0.05m; // 5% for home appliances
	}
}

نعدل الـ DiscountCalculator عشان يستخدم الـ strategy:

public class DiscountCalculatorAfterOCP
{
	// Closed for modification: This class doesn't change when new discount types are added.
	private readonly IDiscountStrategy _discountStrategy;
 
	public DiscountCalculatorAfterOCP(IDiscountStrategy discountStrategy)
	{
		_discountStrategy = discountStrategy; // Dependency is Injected
	}
 
	public decimal CalculateDiscount(Product product)
	{
		// Delegates calculation to the injected strategy
		return _discountStrategy.CalculateDiscount(product);
	}
}

الفايدة من كده إيه؟ لو عايزين نضيف نوع خصم جديد (مثلاً للأدوات المنزلية):

هنعمل class جديدة HomeAppliancesDiscountStrategy : IDiscountStrategy.
لما نيجي نستخدم DiscountCalculatorAfterOCP، هنسلّم ليه الـ instance من الـ strategy الجديدة دي في الـ constructor: new DiscountCalculatorAfterOCP(new HomeAppliancesDiscountStrategy()).

إحنا كده “وسعنا” الـ system بوظيفة جديدة من غير ما “نعدل” أي حاجة في DiscountCalculatorAfterOCP الأصلي أو الـ strategies القديمة. الـ DiscountCalculatorAfterOCP بقى closed for modification و open for extension. اللي عملناه ده مثال على استخدام Strategy Design Pattern.

مثال عملي: `PaymentProcessor`

فالمثال اللي فوق لو جينا نشوف هنلاقيه بيحقق الـ SRP بس مش بيحقق الـ OCP

// Interface for payment strategies
public interface IPaymentStrategy
{
    void ProcessPayment(decimal amount);
}
 
// Concrete payment strategies
public class VisaPaymentStrategy : IPaymentStrategy
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing Visa payment of {amount:C}.");
    }
}
 
public class MasterCardPaymentStrategy : IPaymentStrategy
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing MasterCard payment of {amount:C}.");
    }
}
 
public class AmericanExpressPaymentStrategy : IPaymentStrategy
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing American Express payment of {amount:C}.");
    }
}
 
// New payment strategy (extending functionality)
public class PayPalPaymentStrategy : IPaymentStrategy
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing PayPal payment of {amount:C}.");
    }
}
 
// Payment Processor class - closed for modification
public class PaymentProcessor
{
    private readonly IPaymentStrategy _paymentStrategy;
 
    // Dependency injection through constructor
    public PaymentProcessor(IPaymentStrategy paymentStrategy)
    {
        _paymentStrategy = paymentStrategy;
    }
 
    public void ExecutePayment(Order order) // Assuming Order has a TotalAmount
    {
        // No if/else or switch for payment type here!
        _paymentStrategy.ProcessPayment(order.TotalAmount);
    }
}
 
// Example usage in a Main function or client code
public class OCPClientCode
{
    public static void ProcessOrderPayment()
    {
        Order myOrder = new Order { OrderId = 101, TotalAmount = 150.75m };
 
        // Process with Visa
        IPaymentStrategy visaStrategy = new VisaPaymentStrategy();
        PaymentProcessor visaProcessor = new PaymentProcessor(visaStrategy);
        visaProcessor.ExecutePayment(myOrder);
 
        // Process with PayPal (newly added without modifying PaymentProcessor)
        IPaymentStrategy paypalStrategy = new PayPalPaymentStrategy();
        PaymentProcessor paypalProcessor = new PaymentProcessor(paypalStrategy);
        paypalProcessor.ExecutePayment(myOrder);
    }
}

لو عايزين نضيف طريقة دفع جديدة زي PayPal، كل اللي هنعمله إننا ننشئ class جديدة زي PayPalPaymentStrategy بتعمل implement للـ IPaymentStrategy. الـ PaymentProcessor نفسه مش هيتعدل.

3. Liskov Substitution Principle - LSP

حرف L في SOLID بيرمز للـ Liskov Substitution Principle.

يعني إيه `Liskov Substitution`؟

المبدأ ده بينص على إن: “لو الـ class S هي subclass من الـ class T، يبقى المفروض نقدر نستخدم objects من النوع S مكان objects من النوع T من غير ما نبوظ أي حاجة في البرنامج أو نغير سلوكه المتوقع.”

بمعنى أصح، الـ subclass لازم تحافظ على “عقد” الـ superclass بتاعها. ماينفعش الـ child class يعمل حاجة تخالف اللي الـ parent class بيوعد بيها. لو كلمت method بيعملها الأب، المفروض تتنفذ بالسلوك اللي أنا شايفه في الأب.

مثال: الموظفين وحساب المرتبات (`Employee` & `Salary Calculation`)

تخيل عندنا class اسمها Employee:

public class Employee
{
    public string Name { get; set; }
    public int HoursWorked { get; set; }
 
    // Base salary calculation logic
    public virtual decimal CalculateSalary() // Made virtual to allow override
    {
        // Default calculation, e.g., for a generic employee or contractor
        return HoursWorked * 10.0m; // Example: 10 units per hour
    }
}

وعندنا أنواع مختلفة من الموظفين:

FullTimeEmployee:

public class FullTimeEmployee : Employee
{
	public decimal FixedSalary { get; set; } = 2000.0m; // Example fixed part
 
	public override decimal CalculateSalary()
	{
		// Specific calculation for full-time: fixed salary + bonus for extra hours
		return (HoursWorked * 10.0m) + FixedSalary;
	}
}

PartTimeEmployee:

public class PartTimeEmployee : Employee
{
	public decimal HourlyWage { get; set; } = 8.0m;
 
	public override decimal CalculateSalary()
	{
		// Specific calculation for part-time
		return HoursWorked * HourlyWage;
	}
}

المشكلة: إن لو كل subclass غيرت الـ logic بتاع CalculateSalary بشكل جذري لدرجة إنها مبقتش “تحترم” المعنى الأصلي للميثود في الـ base class، ده ممكن يؤدي لمشاكل. مثلاً، لو CalculateSalary في الـ base class ليها معنى معين (زي إنها مرتبطة مباشرة بعدد الساعات HoursWorked)، وجه subclass عمل override ورجع قيمة ثابتة مالهاش دعوة بـ HoursWorked خالص، ده ممكن يكون violation لو اللي بيستخدم الـ base class بيتوقع سلوك معين بناءً على HoursWorked.

الخلاصة إن الـ override لازم يكون منطقي في سياق الـ base method.

الحل : فصل الـ salary calculation في interface منفصل لو الـ logic بيختلف جداً.

public interface ISalaryCalculator
{
    decimal CalculateSalary(EmployeeDetails details); // EmployeeDetails could hold HoursWorked, Type, etc.
}
 
public class EmployeeDetails // Helper for ISalaryCalculator
{
    public string EmployeeType { get; set; }
    public int HoursWorked { get; set; }
    public decimal BaseRate { get; set; }
    public decimal FixedComponent { get; set; }
}
 
// Base Employee class might not have CalculateSalary directly anymore,
// or it could have a default one if ISalaryCalculator is optional.
public class EmployeeBase // Renamed to avoid confusion
{
    public string Name { get; set; }
    // Other common properties
}
 
 
public class FullTimeEmployeeStrategy : ISalaryCalculator
{
    public decimal CalculateSalary(EmployeeDetails details)
    {
        // Logic specific to full-time, e.g. FixedComponent + (details.HoursWorked * bonusRate)
        Console.WriteLine("C#: Calculating FullTime Employee Salary using Strategy.");
        return details.FixedComponent + (details.HoursWorked * details.BaseRate); // Example logic
    }
}
 
public class PartTimeEmployeeStrategy : ISalaryCalculator
{
    public decimal CalculateSalary(EmployeeDetails details)
    {
        // Logic specific to part-time
        Console.WriteLine("C#: Calculating PartTime Employee Salary using Strategy.");
        return details.HoursWorked * details.BaseRate;
    }
}
 
// Client code would use the strategy
public class SalaryService
{
    private readonly ISalaryCalculator _salaryCalculator;
    private readonly EmployeeDetails _employeeDetails;
 
    public SalaryService(ISalaryCalculator salaryCalculator, EmployeeDetails employeeDetails)
    {
        _salaryCalculator = salaryCalculator;
        _employeeDetails = employeeDetails;
    }
 
    public decimal GetSalary()
    {
        return _salaryCalculator.CalculateSalary(_employeeDetails);
    }
}

بكده، الـ Employee class نفسها (أو EmployeeBase في المثال ده) مبقاش فيها الـ CalculateSalary بالـ logic المختلف، وبقى الـ logic ده موجود في strategies منفصلة. ده بيضمن إن أي EmployeeBase object ليه نفس الخصائص الأساسية، والـ calculation بيتم بطريقة واضحة ومفصولة.

مثال عملي: الطلبات وتكاليف الشحن (`Order` & `ShippingCost`)

// Base Order class
public class OrderLSP
{
    public string Name { get; set; }
    public decimal Price { get; set; }
    // protected decimal ShippingCost { get; set; } // Made protected
 
    public virtual decimal GetTotalPrice()
    {
        // Base implementation might assume some default shipping or that shipping is added by subclasses
        Console.WriteLine($"C#: OrderLSP - GetTotalPrice called for {Name}. Price: {Price}");
        return Price; // Default: price without shipping
    }
}
 
// DeliveryOrder expects shipping to be added
public class DeliveryOrder : OrderLSP
{
    public decimal ShippingCost { get; private set; } = 25.0m; // Example shipping cost
 
    public DeliveryOrder(string name, decimal price)
    {
        Name = name;
        Price = price;
    }
    public override decimal GetTotalPrice()
    {
        decimal basePrice = base.GetTotalPrice(); // Good practice to call base if relevant
        decimal totalPrice = basePrice + ShippingCost;
        Console.WriteLine($"C#: DeliveryOrder - Total for {Name}: {basePrice} + Shipping {ShippingCost} = {totalPrice}");
        return totalPrice;
    }
}
 
// PickupOrder should NOT have shipping costs.
public class PickupOrder : OrderLSP
{
    public PickupOrder(string name, decimal price)
    {
        Name = name;
        Price = price;
    }
    // By inheriting GetTotalPrice from OrderLSP, it correctly returns just the Price,
    // which is what we want for a PickupOrder (no shipping).
    // If OrderLSP's GetTotalPrice always added a base shipping, PickupOrder would have
    // to override it to *remove* or *zero-out* shipping, which could be an LSP violation
    // if clients expect GetTotalPrice to always behave in one way w.r.t shipping.
 
    // If OrderLSP.GetTotalPrice implicitly included a default non-zero shipping cost,
    // PickupOrder would violate LSP if it just returned Price.
    // The current structure is okay.
}

المشكلة (لو الـ base class افترضت سلوك دايماً فيه شحن): لو الـ OrderLSP.GetTotalPrice() كانت دايماً بتضيف رقم شحن (حتى لو صفر)، وجه الـ PickupOrder حب يلغي الشحن ده خالص بطريقة غير متوقعة (مثلاً يطرح قيمة أو يرجع الـ Price بس لما الـ client متوقع إن الشحن محسوب)، ده ممكن يبقى LSP violation.

الحل المقترح (فصل حساب الشحن):

public interface IShippingCostCalculator
{
    decimal CalculateShippingCost(OrderLSP order);
}
 
public class StandardShippingCalculator : IShippingCostCalculator
{
    public decimal CalculateShippingCost(OrderLSP order)
    {
        // Logic for standard shipping, maybe based on weight, distance, or a flat fee
        return 25.0m; // Example flat fee
    }
}
 
public class NoShippingCalculator : IShippingCostCalculator // For Pickup Orders
{
    public decimal CalculateShippingCost(OrderLSP order)
    {
        return 0m; // No shipping cost
    }
}
 
// Modified OrderLSP to use the calculator strategy
public class OrderLSP_Refactored
{
    public string Name { get; set; }
    public decimal Price { get; set; }
    private readonly IShippingCostCalculator _shippingCalculator;
 
    public OrderLSP_Refactored(string name, decimal price, IShippingCostCalculator shippingCalculator)
    {
        Name = name;
        Price = price;
        _shippingCalculator = shippingCalculator;
    }
 
    public decimal GetTotalPrice()
    {
        decimal shipping = _shippingCalculator.CalculateShippingCost(this); // 'this' might not be needed if calculator has all info
        Console.WriteLine($"C#: OrderLSP_Refactored - Price: {Price}, Shipping: {shipping}");
        return Price + shipping;
    }
}
 
// Client code would then provide the correct calculator
// var deliveryOrder = new OrderLSP_Refactored("Laptop", 1200, new StandardShippingCalculator());
// var pickupOrder = new OrderLSP_Refactored("Mouse", 25, new NoShippingCalculator());
// Console.WriteLine(deliveryOrder.GetTotalPrice());
// Console.WriteLine(pickupOrder.GetTotalPrice());

كده الـ base class (OrderLSP_Refactored) نفسها مبقتش مسؤولة عن الـ logic الخاص بحساب تكلفة الشحن، والـ Subtypes (DeliveryOrder و PickupOrder) بيتم تحديد سلوك الشحن بتاعهم عن طريق IShippingCostCalculator اللي بيتم حقنه. أي object من OrderLSP_Refactored هيتصرف بشكل متوقع بناءً على الـ calculator اللي معاه.

4. Interface Segregation Principle - ISP

حرف I في SOLID بيرمز للـ Interface Segregation Principle.

يعني إيه `Interface Segregation`؟

المبدأ ده بسيط وبيقول: “مفيش code المفروض يكون مجبر إنه يعتمد على methods هو مش هيستخدمها أو مش هيعملها implementation.”

الـ ISP بيقولك قسم الـ interfaces الكبيرة (اللي فيها methods كتير، بيسموها “fat interfaces”) لـ interfaces أصغر وأكثر تخصصًا (بيسموها “role interfaces” أو “fine-grained interfaces”). كل class تعمل implement للـ interface اللي فيه الـ methods اللي هي محتاجاها فعلاً بس.

مثال: مدير المهام (`TaskManager`)

لتوضيح الفكرة، هنفترض وجود الكلاسات دي:

public class TaskItem // Helper class
{
    public int Id { get; set; }
    public string Description { get; set; }
}
 
public class User // Helper class
{
    public string Name { get; set; }
}

تخيل عندنا interface اسمه ITaskManagerFat بيعمل حاجات كتير:

// "Fat" interface - Bad example
public interface ITaskManagerFat
{
    void CreateTask(TaskItem task);
    void AssignTask(TaskItem task, User user);
    void SendNotification(TaskItem task, string message); // Notification-related method
}

وعندنا TaskService بيعمل implement للـ interface ده:

public class TaskServiceUsingFatInterface : ITaskManagerFat
{
    public void CreateTask(TaskItem task)
    {
        Console.WriteLine($"C#: TaskService - Task '{task.Description}' created.");
    }
 
    public void AssignTask(TaskItem task, User user)
    {
        Console.WriteLine($"C#: TaskService - Task '{task.Description}' assigned to {user.Name}.");
    }
 
    // This TaskService might not be responsible for sending notifications,
    // but it's forced to implement it because of the fat interface.
    public void SendNotification(TaskItem task, string message)
    {
        Console.WriteLine($"C#: TaskService - (Forced Impl) Notification for '{task.Description}': {message}. Maybe not its job.");
        // Or it might throw new NotSupportedException("SendNotification is not supported by TaskService.");
        // Or leave it empty. All are bad signs.
    }
}

المشكلة هنا إيه؟

الـ SRP violation (محتمل): الـ TaskService بقى مسؤول عن إدارة المهام وكمان إرسال الإشعارات (لو هو اللي بينفذها فعلاً).
ISP violation:
- الـ TaskServiceUsingFatInterface مجبر يعمل implement للـ SendNotification حتى لو مش هيستخدمها أو مش دي مسؤوليته. ممكن يسيب الـ method body فاضي أو يرمي NotSupportedException.
- لو عندنا class تانية كل همها إرسال الإشعارات (مثلاً StandaloneNotificationService)، هتضطر تعمل implement للـ ITaskManagerFat كله، بما فيه CreateTask و AssignTask اللي هي مش محتاجاهم، بس عشان تستخدم SendNotification.

الحل (تطبيق الـ ISP): نقسم الـ interface الكبير لـ interfaces أصغر وأكثر تخصصًا:

الـ ITaskOperations: للعمليات الخاصة بالمهام فقط.

// Interface for task operations
public interface ITaskOperations
{
	void CreateTask(TaskItem task);
	void AssignTask(TaskItem task, User user);
}

الـ INotificationService: لعمليات إرسال الإشعارات فقط.

// Interface for notification sending
public interface INotificationService // Renamed for clarity from INotificationSender
{
	void SendNotification(string recipientIdentifier, string message); // More generic now
}

الـ classes بعد التعديل:

الـ TaskManagementService هيعمل implement للـ ITaskOperations:

public class TaskManagementService : ITaskOperations // Implements only what it needs
{
	public void CreateTask(TaskItem task)
	{
		Console.WriteLine($"C#: TaskManagementService - Task '{task.Description}' created.");
	}
 
	public void AssignTask(TaskItem task, User user)
	{
		Console.WriteLine($"C#: TaskManagementService - Task '{task.Description}' assigned to {user.Name}.");
	}
	// Not forced to implement SendNotification
}

لو فيه class مسؤولة عن الإشعارات (زي EmailNotificationService)، هتعمل implement للـ INotificationService:

public class EmailNotificationService : INotificationService
{
	public void SendNotification(string emailAddress, string message)
	{
		Console.WriteLine($"C#: EmailNotificationService - Email sent to {emailAddress}: {message}");
	}
}

لو الـ TaskManagementService محتاج يبعت إشعارات، ممكن “يستخدم” (يعمل composition ويحقن dependency) لـ instance من INotificationService، أو ممكن حتى يختار يعمل implement لـ INotificationService هو كمان لو ده منطقي في سياقه (مع الحذر من مخالفة SRP). الـ TaskManagementService مبقاش مجبر يعمل implement لحاجة مش هيستخدمها.

مثال عملي: `UserManagement`

لتوضيح الفكرة، هنفترض وجود الكلاسات دي:

// Helper class for User
// public class User { public string Name { get; set; } /* ... other properties ... */ } already defined
// Helper class for Product
// public class Product { public string Name { get; set; } /* ... other properties ... */ } already defined

تخيل عندنا IUserManagementFat interface:

// Original "fat" interface
public interface IUserManagementFat
{
    void UpdateUserProfile(User user);
    void ChangePassword(User user, string newPassword);
    void SubscribeToNewProductAvailability(User user, Product product);
    void SubscribeToSmsNotifications(User user, string topic);
}

وعندنا Customer بيعمل implement لكل دول. لكن عندنا GuestSubscriber (ممكن يكون guest user عمل subscribe من غير account كامل)، هو بس عايز يعمل subscribe لـ product availability أو SMS notifications، ومش محتاج UpdateUserProfile أو ChangePassword. هنا الـ GuestSubscriber مجبر يعمل implement لـ methods مش هيستخدمها.

الحل (تطبيق الـ ISP):

الـ IAccountManagement: للعمليات الخاصة بالحساب.

// Interface for account specific actions
public interface IAccountManagement
{
	void UpdateUserProfile(User user);
	void ChangePassword(User user, string newPassword);
}

الـ ISubscriptionManagement: للعمليات الخاصة بالاشتراكات.

// Interface for subscription actions
public interface ISubscriptionManagement // Renamed from ISubscriptionService for clarity
{
	void SubscribeToNewProductAvailability(User user, Product product);
	void SubscribeToSmsNotifications(User user, string topic);
}

الـ classes بعد التعديل:

الـ RegisteredCustomer هيعمل implement للاتنين: IAccountManagement و ISubscriptionManagement.

public class RegisteredCustomer : IAccountManagement, ISubscriptionManagement
{
	private User _user;
	public RegisteredCustomer(User user) { _user = user; }
 
	// From IAccountManagement
	public void UpdateUserProfile(User user) { Console.WriteLine($"C#: RegisteredCustomer {_user.Name} profile updated."); }
	public void ChangePassword(User user, string newPassword) { Console.WriteLine($"C#: RegisteredCustomer {_user.Name} password changed."); }
 
	// From ISubscriptionManagement
	public void SubscribeToNewProductAvailability(User user, Product product) { Console.WriteLine($"C#: RegisteredCustomer {_user.Name} subscribed to product {product.Name}."); }
	public void SubscribeToSmsNotifications(User user, string topic) { Console.WriteLine($"C#: RegisteredCustomer {_user.Name} subscribed to SMS for {topic}."); }
}

الـ GuestSubscriber هيعمل implement للـ ISubscriptionManagement بس.

public class GuestSubscriber : ISubscriptionManagement // Only needs subscription capabilities
{
	private User _user; // Could be a simpler representation like just an email or phone
	public GuestSubscriber(User user) { _user = user; }
 
	// From ISubscriptionManagement
	public void SubscribeToNewProductAvailability(User user, Product product) { Console.WriteLine($"C#: GuestSubscriber for {_user.Name} subscribed to product {product.Name}."); }
	public void SubscribeToSmsNotifications(User user, string topic) { Console.WriteLine($"C#: GuestSubscriber for {_user.Name} subscribed to SMS for {topic}."); }
	// Not forced to implement account management methods
}

كده كل class بتاخد الـ interface اللي يناسبها ومبقاش في إجبار على methods مش هتستخدمها.

5. Dependency Inversion Principle - DIP

حرف D في SOLID بيرمز للـ Dependency Inversion Principle. ركزوا في ده عشان مهم وناس كتير بتتلخبط فيه.

يعني إيه `Dependency Inversion`؟

المبدأ ده بينص على حاجتين:

الـ high-level modules مينفعش تعتمد مباشرة على الـ low-level modules. الاتنين لازم يعتمدوا على Abstraction (زي الـ interfaces أو abstract classes).
الـ abstractions نفسها مينفعش تعتمد على التفاصيل (الـ concrete implementations). العكس هو الصحيح: التفاصيل (الـ concrete classes) هي اللي المفروض تعتمد على الـ abstractions (عن طريق إنها تعملها implement أو تورث منها).

يعني إيه الكلام ده؟ تخيل عندك OrderProcessingService (ده high-level module لأنه فيه business logic ومسؤول عن تنسيق عملية كبيرة). وعندك MySqlOrderDataAccess (ده low-level module لأنه تفصيلة تقنية للوصول للداتا بيز).

لو الـ OrderProcessingService بيعمل new MySqlOrderDataAccess() جواه مباشرة، كده الـ high-level بيعتمد على تفصيلة low-level (concrete implementation). ده بيخلي الـ service بتاعتك مربوطة جامد بالـ MySQL. لو حبيت تغير لـ PostgreSQL أو تستخدم mock في الـ testing، هتبقى مشكلة.

الـ DIP بيقولك لأ، متعملش كده. خلي الاتنين يعتمدوا على abstraction:

الـ OrderProcessingService (high-level) يعتمد على interface (مثلاً IOrderDataAccess).
الـ MySqlOrderDataAccess (low-level) يعمل implement للـ interface IOrderDataAccess.
يتم “حقن” (inject) الـ concrete implementation (زي MySqlOrderDataAccess) جوه الـ OrderProcessingService (عادةً عن طريق الـ constructor).

كده الاتنين (الـ high-level والـ low-level) بقوا بيعتمدوا على abstraction زي (IOrderDataAccess). والاعتمادية اتعكست: بدل ما الـ business logic بيشاور على الـ data access، بقى الـ data access هو اللي بيشاور (بيعمل implement) للـ abstraction اللي الـ business logic بيعرفها وبيستخدمها.

مثال: `OrderManagementService` و `OrderDataAccess`

الشكل الغلط (مخالفة الـ DIP) - هاي ليفل بيعتمد على لو ليفل:

// Low-level module (concrete data access implementation)
public class MySqlOrderDataAccessNoDIP
{
    public List<Order> FetchAllOrdersFromDB()
    {
        Console.WriteLine("C#: MySqlOrderDataAccessNoDIP - Fetching all orders from MySQL.");
        // Actual database query logic here
        return new List<Order>();
    }
    // Other methods like SaveOrder, etc.
}
 
// High-level module directly depending on the low-level concrete class
public class OrderManagementServiceNoDIP
{
    private readonly MySqlOrderDataAccessNoDIP _dataAccess; // Direct dependency on a CONCRETE class
 
    public OrderManagementServiceNoDIP()
    {
        // Instantiation of concrete class inside the high-level module
        _dataAccess = new MySqlOrderDataAccessNoDIP();
    }
 
    public List<Order> GetAndProcessOrders()
    {
        Console.WriteLine("C#: OrderManagementServiceNoDIP - Getting and processing orders.");
        List<Order> orders = _dataAccess.FetchAllOrdersFromDB();
        // Further processing logic on orders...
        return orders;
    }
}

هنا الـ OrderManagementServiceNoDIP (high-level) بيعتمد مباشرة على MySqlOrderDataAccessNoDIP (low-level).

الحل (تطبيق الـ DIP) - الاتنين بيعتمدوا على أبستراكشن:

نعمل abstraction (interface) للداتا أكسس:

// Abstraction (Interface) for data access
public interface IOrderDataAccess // Renamed from IOrderRepository for consistency with video's naming flow
{
	List<Order> FetchAllOrders();
	// void SaveOrder(Order order); // Example of other methods
}

الـ low-level modules (التفاصيل) تعمل implement للـ interface:

// Low-level module (concrete MySQL implementation) implementing the abstraction
public class MySqlOrderDataAccess : IOrderDataAccess
{
	public List<Order> FetchAllOrders()
	{
		Console.WriteLine("C#: MySqlOrderDataAccess - Fetching all orders from MySQL (via IOrderDataAccess).");
		return new List<Order>();
	}
}
 
// Another possible low-level module (concrete MongoDB implementation)
public class MongoDbOrderDataAccess : IOrderDataAccess
{
	public List<Order> FetchAllOrders()
	{
		Console.WriteLine("C#: MongoDbOrderDataAccess - Fetching all orders from MongoDB (via IOrderDataAccess).");
		return new List<Order>();
	}
}

الـ high-level module يعتمد على الـ interface (عادةً عن طريق الـ constructor injection):

// High-level module depending on the abstraction (IOrderDataAccess)
public class OrderManagementServiceWithDIP
{
	private readonly IOrderDataAccess _dataAccessProvider; // Depends on ABSTRACTION
 
	// Dependency is injected via constructor (Constructor Injection)
	public OrderManagementServiceWithDIP(IOrderDataAccess dataAccessProvider)
	{
		_dataAccessProvider = dataAccessProvider;
	}
 
	public List<Order> GetAndProcessOrders()
	{
		Console.WriteLine("C#: OrderManagementServiceWithDIP - Getting and processing orders using injected provider.");
		List<Order> orders = _dataAccessProvider.FetchAllOrders(); // Uses the abstraction
		// Further processing logic on orders...
		return orders;
	}
}

بنطبق الـ DIP عن طريق الـ Dependency Injection (DI) واللي عملناه فوق دا اسمه Constructor Injection ودا نوع من انواعه

الفايدة من كده إيه؟

الـ OrderManagementServiceWithDIP مبقاش مربوط بنوع database معين. نقدر نديله أي class بتعمل implement للـ IOrderDataAccess (سواء MySqlOrderDataAccess أو MongoDbOrderDataAccess أو حتى InMemoryDataAccess عشان الـ testing).
ده بيسهل الـ testing جداً (باستخدام mock objects للـ IOrderDataAccess).
بيزود الـ flexibility و الـ extensibility للـ system.
الاعتمادية اتعكست: بدل ما الـ high-level module (الـService) بيعرف وبيعمل instantiate للـ low-level module (الـ Data Access)، بقى الـ high-level module بيعتمد على abstraction اللي هو (interface)، والـ low-level module هو اللي بيعمل implement للـ abstraction دي. والـ client أو الـ Dependency Injection Container هو اللي بيربطهم ببعض.

مثال عملي سابق (PaymentProcessor و IPaymentStrategy): مثال الـ PaymentProcessor اللي استخدمناه في شرح الـ OCP هو كمان بيطبق الـ DIP بشكل كويس:

الـ PaymentProcessor (high-level module) كان بيعتمد على IPaymentStrategy (abstraction).
الـ concrete strategies زي VisaPaymentStrategy، MasterCardPaymentStrategy (low-level modules/التفاصيل) كانوا بيعملوا implement للـ IPaymentStrategy.
كنا بنعمل inject (حقن) للـ concrete strategy في الـ constructor بتاع الـ PaymentProcessor.

// class PaymentProcessor
// {
//     private readonly IPaymentStrategy _paymentStrategy; // Depends on ABSTRACTION
//
//     public PaymentProcessor(IPaymentStrategy paymentStrategy) // DIP happens here via Constructor Injection
//     {
//         _paymentStrategy = paymentStrategy;
//     }
//
//     public void ExecutePayment(Order order)
//     {
//         _paymentStrategy.ProcessPayment(order.TotalAmount); // Uses the abstraction
//     }
// }

بكده، فصلنا الاعتمادية بتاعة الـ PaymentProcessor عن نوع الدفع اللي هيجيله، وخلينا الاتنين (الـ high-level والـ low-level) يعتمدوا على abstraction.

خلاصة مبادئ SOLID

كده إحنا شوفنا مع بعض الخمس مبادئ بتوع SOLID وأهميتهم:

الـ S - Single Responsibility Principle: الـ class يكون ليها سبب واحد بس للتغيير.
الـ O - Open/Closed Principle: الـ code يكون مفتوح للتوسيع (بإضافة functionality جديدة من غير تعديل الكود القديم) ومقفول عن التعديل المباشر (في الكود القديم اللي شغال وثابت).
الـ L - Liskov Substitution Principle: نقدر نستخدم object من subclass مكان object من parent class من غير ما البرنامج يضرب أو سلوكه يتغير بشكل غير متوقع. الـchild لازم يحترم “عقد” الـ parent.
الـ I - Interface Segregation Principle: متجبرش class إنها تعمل implement لـ methods هي مش محتاجاها؛ قسم الـ interfaces الكبيرة لـ interfaces أصغر وأكثر تخصصًا.
الـ D - Dependency Inversion Principle: الـ high-level modules متعتمدش على low-level modules مباشرة، الاتنين يعتمدوا على abstractions. والتفاصيل هي اللي تعتمد على الـ abstractions، مش العكس.

تطبيق المبادئ دي بيخلي الـ software بتاعنا أحسن بكتير من حيث الجودة، وسهولة الصيانة، والقابلية للتوسع والاختبار.

🍿 CornPop

Explorer

Learn SOLID Principles in Arabic

1. Single Responsibility Principle - SRP

يعني إيه `Single Responsibility`؟

مثال: خدمة الإيميلات (`EmailingService`)

مثال عملي: `OrderManager`

2. Open-Closed Principle - OCP

يعني إيه `Open/Closed`؟

مثال: حاسبة الخصومات (`DiscountCalculator`)

مثال عملي: `PaymentProcessor`

3. Liskov Substitution Principle - LSP

يعني إيه `Liskov Substitution`؟

مثال: الموظفين وحساب المرتبات (`Employee` & `Salary Calculation`)

مثال عملي: الطلبات وتكاليف الشحن (`Order` & `ShippingCost`)

4. Interface Segregation Principle - ISP

يعني إيه `Interface Segregation`؟

مثال: مدير المهام (`TaskManager`)

مثال عملي: `UserManagement`

5. Dependency Inversion Principle - DIP

يعني إيه `Dependency Inversion`؟

مثال: `OrderManagementService` و `OrderDataAccess`

خلاصة مبادئ SOLID

Graph View

Table of Contents

Backlinks

🍿 CornPop

Explorer

Learn SOLID Principles in Arabic

1. Single Responsibility Principle - SRP

يعني إيه Single Responsibility؟

مثال: خدمة الإيميلات (EmailingService)

مثال عملي: OrderManager

2. Open-Closed Principle - OCP

يعني إيه Open/Closed؟

مثال: حاسبة الخصومات (DiscountCalculator)

مثال عملي: PaymentProcessor

3. Liskov Substitution Principle - LSP

يعني إيه Liskov Substitution؟

مثال: الموظفين وحساب المرتبات (Employee & Salary Calculation)

مثال عملي: الطلبات وتكاليف الشحن (Order & ShippingCost)

4. Interface Segregation Principle - ISP

يعني إيه Interface Segregation؟

مثال: مدير المهام (TaskManager)

مثال عملي: UserManagement

5. Dependency Inversion Principle - DIP

يعني إيه Dependency Inversion؟

مثال: OrderManagementService و OrderDataAccess

خلاصة مبادئ SOLID

Graph View

Table of Contents

Backlinks

يعني إيه `Single Responsibility`؟

مثال: خدمة الإيميلات (`EmailingService`)

مثال عملي: `OrderManager`

يعني إيه `Open/Closed`؟

مثال: حاسبة الخصومات (`DiscountCalculator`)

مثال عملي: `PaymentProcessor`

يعني إيه `Liskov Substitution`؟

مثال: الموظفين وحساب المرتبات (`Employee` & `Salary Calculation`)

مثال عملي: الطلبات وتكاليف الشحن (`Order` & `ShippingCost`)

يعني إيه `Interface Segregation`؟

مثال: مدير المهام (`TaskManager`)

مثال عملي: `UserManagement`

يعني إيه `Dependency Inversion`؟

مثال: `OrderManagementService` و `OrderDataAccess`