اصول SOLID

مشکل: کدی که با هر تغییر می‌شکند

فروشگاه اینترنتی ما یک کلاس OrderService دارد. اول کوچک بود. حالا قیمت را حساب می‌کند، کالا را رزرو می‌کند، پول را می‌گیرد و ایمیل تبلیغاتی می‌فرستد.

هر ماه یک اتفاق تکراری می‌افتد:

1. تیم بازاریابی متن ایمیل را عوض می‌کند. یک برنامه‌نویس OrderService را باز می‌کند.
2. یک خط اشتباه در همان فایل، محاسبه قیمت را خراب می‌کند. کسی انتظارش را نداشت.
3. برای تست ایمیل، باید دیتابیس، درگاه پرداخت و سرور ایمیل را آماده کنی. پس تستی نوشته نمی‌شود.

اصول SOLID پنج قانون ساده برای همین مشکل است. هر حرف یک اصل است:

اصل اول (S): یک دلیل برای تغییر

«یک مسئولیت» یعنی چه؟ «فقط یک کار» تعریف مبهمی است. تعریف بهتر این است: کلاس فقط باید به یک گروه از آدم‌ها جواب بدهد. هر گروه دلیل خودش را برای تغییر دارد.

چرا این مهم است؟

1. تغییر یک تیم، کار تیم دیگر را خراب نمی‌کند. متن ایمیل در کلاسی است که هیچ ربطی به قیمت ندارد.
2. کلاس‌ها کوچک می‌شوند. هر کدام فقط وابستگی‌های خودش را دارد.
3. تست ساده می‌شود. برای تست قیمت، فقط به کلاس قیمت نیاز داری.

بعد از جدا کردن، OrderService فقط کارها را هماهنگ می‌کند. خودش قانونی را اجرا نمی‌کند:

public sealed class PlaceOrderService(
    PriceCalculator prices,
    IStockReservation stock,
    IOrderRepository orders)
{
    public async Task<Guid> PlaceAsync(Order order, CancellationToken ct)
    {
        order.SetTotal(prices.Calculate(order));
        await stock.ReserveAsync(order, ct);
        await orders.AddAsync(order, ct);
        return order.Id;
    }
}

اصل دوم (O): باز برای اضافه شدن، بسته برای تغییر

تیم فروش هر چند هفته یک تخفیف تازه می‌خواهد: تخفیف مشتری ویژه، تخفیف نوروز، تخفیف اولین خرید. اگر همه در یک switch باشند، هر تخفیف جدید یعنی باز کردن و تغییر یک کد تست‌شده.

راه بهتر این است: یک اینترفیس برای «قانون تخفیف» بساز. هر تخفیف یک کلاس جدا است.

public interface IDiscountRule
{
    decimal Apply(Order order, decimal amount);
}

public sealed class VipDiscount : IDiscountRule
{
    public decimal Apply(Order order, decimal amount) =>
        order.Customer.IsVip ? amount * 0.9m : amount;
}

public sealed class PriceCalculator(IEnumerable<IDiscountRule> rules)
{
    public decimal Calculate(Order order) =>
        rules.Aggregate(order.Subtotal, (amount, rule) => rule.Apply(order, amount));
}

ثبت در DI:

builder.Services.AddScoped<IDiscountRule, VipDiscount>();
builder.Services.AddScoped<IDiscountRule, NowruzDiscount>();
builder.Services.AddScoped<PriceCalculator>();

حالا تخفیف جدید یعنی یک کلاس جدید و یک خط ثبت. کلاس PriceCalculator هیچ وقت عوض نمی‌شود. این همان الگوی Strategy است که در درس الگوهای طراحی می‌بینی.

اصل سوم (L): جایگزینی بدون غافلگیری

هر کلاسی که یک اینترفیس را پیاده‌سازی می‌کند، یک قول می‌دهد. کدی که با اینترفیس کار می‌کند، به این قول اعتماد دارد. اصل لیسکوف می‌گوید: هر پیاده‌سازی باید همان قول را نگه دارد.

فروشگاه ما سه روش پرداخت دارد: کارت بانکی، کیف پول و کارت هدیه. همه یک اینترفیس دارند:

public interface IPaymentMethod
{
    Task PayAsync(Order order, CancellationToken ct);
    Task RefundAsync(Order order, CancellationToken ct);
}

public sealed class GiftCardPayment : IPaymentMethod
{
    public Task PayAsync(Order order, CancellationToken ct) => Task.CompletedTask; // simplified

    public Task RefundAsync(Order order, CancellationToken ct) =>
        throw new NotSupportedException("Gift cards cannot be refunded.");
}

کد لغو سفارش برای همه روش‌ها RefundAsync را صدا می‌زند. با کارت بانکی کار می‌کند. با کارت هدیه، در زمان اجرا خطا می‌دهد. کامپایلر هیچ هشداری نداد.

یک پیاده‌سازی خوب این سه قانون را نگه می‌دارد:

1. ورودی سخت‌گیرانه‌تر نخواهد. اگر اینترفیس هر سفارشی را قبول می‌کند، پیاده‌سازی نگوید «فقط سفارش بالای یک میلیون».
2. خروجی ضعیف‌تر ندهد. اگر قول داده همیشه نتیجه برگرداند، گاهی null برنگرداند.
3. خطای غافلگیرکننده ندهد. خطایی مثل NotSupportedException برای متدی که قول داده شده، نشانه شکستن این اصل است.

اصل چهارم (I): اینترفیس کوچک

مشکل کارت هدیه از کجا آمد؟ از یک اینترفیس بزرگ. اینترفیس همه روش‌های پرداخت را مجبور کرد برگشت پول را هم داشته باشند. اصل چهارم می‌گوید: کسی را مجبور نکن به متدی وابسته باشد که لازم ندارد.

public interface IPaymentMethod
{
    Task PayAsync(Order order, CancellationToken ct);
}

public interface IRefundable
{
    Task RefundAsync(Order order, CancellationToken ct);
}

public sealed class CardPayment : IPaymentMethod, IRefundable { /* ... */ }
public sealed class GiftCardPayment : IPaymentMethod { /* ... */ }

کد لغو سفارش حالا فقط با IRefundable کار می‌کند. اگر روش پرداخت برگشت پول ندارد، این را از همان اول می‌داند و می‌تواند مثلاً اعتبار هدیه جدید بدهد.

• نشانه بدی اینترفیس: پیاده‌سازی‌هایی که چند متد را خالی می‌گذارند یا خطا می‌دهند.
• اندازه درست: اینترفیس را بر اساس نیاز استفاده‌کننده بساز، نه بر اساس همه کارهایی که کلاس می‌تواند انجام دهد.

اصل پنجم (D): وارونگی وابستگی

سرویس ثبت سفارش بعد از ثبت، به مشتری خبر می‌دهد. نسخه اول، کلاس ایمیل را مستقیم می‌سازد. حالا اگر بخواهیم پیامک بفرستیم، باید منطق سفارش را عوض کنیم. یعنی بخش مهم (سیاست کسب‌وکار) به بخش کم‌اهمیت (جزئیات فنی) وابسته است.

راه حل سه قدم دارد:

1. بخش سفارش یک اینترفیس تعریف می‌کند. این اینترفیس به زبان سفارش است: «به مشتری خبر بده که سفارش ثبت شد.» کلمه ایمیل در آن نیست.
2. سرویس سفارش فقط این اینترفیس را می‌شناسد. آن را در سازنده می‌گیرد.
3. کلاس ایمیل این اینترفیس را پیاده‌سازی می‌کند. حالا جزئیات به سیاست وابسته است.

// Owned by the ordering code. It speaks the business language.
public interface IOrderNotifier
{
    Task OrderPlacedAsync(Order order, CancellationToken ct);
}

// Infrastructure detail. It depends on the interface above.
public sealed class EmailOrderNotifier(IEmailClient email) : IOrderNotifier
{
    public Task OrderPlacedAsync(Order order, CancellationToken ct) =>
        email.SendAsync(order.CustomerEmail, "Your order is placed", ct);
}

builder.Services.AddScoped<IOrderNotifier, EmailOrderNotifier>();

فردا پیامک لازم شد؟ یک کلاس SmsOrderNotifier می‌نویسی و فقط خط ثبت را عوض می‌کنی. در تست هم یک نسخه ساختگی از IOrderNotifier کافی است.

اصل‌ها با هم کار می‌کنند

این پنج اصل جدا از هم نیستند. در مثال ما:

• با جدا کردن مسئولیت‌ها (S)، کلاس‌های کوچکی داریم که هر کدام یک کار دارند.
• با اینترفیس کوچک (I)، هر کلاس فقط قولی را می‌دهد که نگه می‌دارد. پس جایگزینی (L) امن است.
• با وارونگی وابستگی (D)، کلاس جدید بدون تغییر کد قدیمی وصل می‌شود. پس کد برای اضافه شدن باز است (O).

اشتباه‌های رایج

چه وقت سخت‌گیر باشیم؟